Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1357564 - RFE: allow downloading of mock profiles (reproducible builds)
Summary: RFE: allow downloading of mock profiles (reproducible builds)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Copr
Classification: Community
Component: frontend
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact:
URL:
Whiteboard:
Depends On: 1272381
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-18 13:58 UTC by Pavel Raiskup
Modified: 2016-09-21 13:02 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of: 1272381
Environment:
Last Closed: 2016-09-21 13:02:23 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1357562 None None None Never

Internal Links: 1357562

Description Pavel Raiskup 2016-07-18 13:58:07 UTC
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 +++

Comment 1 clime 2016-07-27 10:19:38 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.

Comment 2 Pavel Raiskup 2016-07-27 10:56:10 UTC
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.

Comment 3 clime 2016-08-12 22:00:04 UTC
"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.

Comment 4 clime 2016-08-19 08:33:33 UTC
Fixed by https://github.com/fedora-copr/copr/commit/c5753574.

Comment 5 Pavel Raiskup 2016-08-19 10:29:40 UTC
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).

Comment 6 clime 2016-09-21 13:02:23 UTC
New COPR version has been deployed (to be released).


Note You need to log in before you can comment on or make changes to this bug.