Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1357564
Summary: | RFE: allow downloading of mock profiles (reproducible builds) | ||
---|---|---|---|
Product: | [Community] Copr | Reporter: | Pavel Raiskup <praiskup> |
Component: | frontend | Assignee: | Miroslav Suchý <msuchy> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | clime, extras-qa, jdisnard, mebrown, Mikhail_Campos-Guadamuz, msimacek, msuchy, praiskup, williams |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | 1272381 | Environment: | |
Last Closed: | 2016-09-21 13:02:23 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1272381 | ||
Bug Blocks: |
Description
Pavel Raiskup
2016-07-18 13:58:07 UTC
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. 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). |