When maintainers play with advanced options in Copr, it is some nontrivial job to generate mock profile against copr to reproduce builds locally, while it is usually desired as local builds are much faster and we have 'mock --shell' available. ---- I initially thought about $Summary only as 'RFE: copy mock profile into build results on backend'. But it wouldn't be much wise to provide the mock profile as-is -- because it is modified rather nontrivially (I'm not sure, but I bet e.g. those fedora/updates repositories used by mock are not accessible by normal users outside from copr environment?). With the bug 1272381 implemented, we can easily generate mock profile which will include the user's-system-default profile and just add the things which are necessary. This might be done easily on front-end, if we had packaged some easy mock-profile generator. As a part of this change, we should have something like $ copr-cli mock-config COPRID --arch > my-copr-config This somehow complements also the bug 1357562. +++ This bug was initially created as a clone of Bug #1272381 +++
I actually thought about including resulting mock config in the build dir but then postponed it because of slightly non-trivial implementation (just really really slightly though). Wouldn't that be a good compromise? I am not sure if the config can be immediately used locally (gonna try) but the changes to do so should be few. On the other hand, to have something like copr-cli mock-config COPRID <...some params...> is not feasible with our current infrastructure. Mock configs are present on builders and modified by backend service with ansible in the build time and this logic is just not accessible to copr-cli. We could use the new include directive (Bug 1272381) of mock configs to perhaps make this backend config-generation process a (very) little bit cleaner but I am not sure if it's really worth the price. And the idea to move the logic for generation of mock configs (or just the variable parts) into frontend is alright but it includes really a non-trivial amount of work. If the configs were present in the build dirs in the end of a build, on the other hand, you could easily fetch them by the already present command 'download-build' so this seems to me as a good viable alternative to enable this use-case of reproducible builds.
I agree with most of the things, except that ... (In reply to clime from comment #1) > We could use the new include directive (Bug 1272381) of mock configs to > perhaps make this backend config-generation process a (very) little bit > cleaner but I am not sure if it's really worth the price. > > And the idea to move the logic for generation of mock configs (or just the > variable parts) into frontend is alright but it includes really a > non-trivial amount of work. ... I believe this is worth the work. Having independent builders would be huge win and doing this shouldn't be _that_ big problem: * builder machine just needs to know what Copr instance is it run against (to know where dist-git is to create srpm, where is frontend to get mock profile, where is backend to access copr repositories) * we must have defined inputs (what command can be run) and outputs (where will be prepared build results for backend) > If the configs were present in the build dirs in the end of a build, on the > other hand, you could easily fetch them by the already present command > 'download-build' so this seems to me as a good viable alternative to enable > this use-case of reproducible builds. Hmm, what I usually want - and what people ask for - is to have the "actual" mock profile I'm able to build against (so I can ensure on my box that the build looks fine until I submit the build in cloud). The file in build results would actually serve rather "historical" point of view. Also, as the file rarely changes, those files would be duplicates most of the time.
"Having independent builders" and "allowing to download mock profiles" are separate issues and there is no clear connection between them. Also, frontend service is designed to be independent of the actual package building mechanism. We would like to keep it that way. I, however, agree it would be nice to provide mock configs after a build.
Fixed by https://github.com/fedora-copr/copr/commit/c5753574.
Thanks for the commit! (In reply to clime from comment #3) > Also, frontend service is designed to be independent of the actual package > building mechanism. We would like to keep it that way. I can appreciate this, makes sense. As long as there is frontend's API to get all the necessary info about coprs (packages to be installed into minimal buildroot, additional repositories), self-standing builder can generate the mock-profile itself (probably through copr-cli, as that already speaks the copr API language).
New COPR version has been deployed (to be released).