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).