On Wed, Aug 23, 2017 at 3:17 PM, Igor Gnatenko <
-----BEGIN PGP SIGNED MESSAGE-----
On Wed, 2017-08-23 at 13:47 +0200, Miroslav Suchý wrote:
> I am gathering informations about various use of CI with Copr. Do you
> use Copr for building packages for nightlies? For
> building packages before pull request is merged? Do you have your set
> up described somewhere? What is the name of your
We do! Both. Our project name is: DNF 😛
So our setup is pretty simple, our tool clones multiple repositories
locally, builds SRPMs for them (it might be spec in upstream or
upstream repo + downstream spec) and then creates temporary COPR
repository and builds RPMs in there. Then we download those RPMs
locally and do something with them (build container with them and run
> Please let me know. Either here or via private reply.
> It will help me to understand your use of Copr and to make Copr
I would like to see:
* only one and supported / good API
Yes, we will need to work on this...very soon.
* probably ability for some good integration with custom tools as we
I will need to study this more.
* or ability to push custom specs / sources into git repo so we
need to build SRPMs locally, we would just do git commit + git push and
COPR would build everything
This should be possible with our SCM source types. It would be nice to
have just one SCM source type which is a goal but even now that should
be possible. Please, let me know if you see any blocker in this. That could
be very interesting input.
* "Temporary" repositories -- repositories which
removed after some time, we need such repos for pull request testing
and after few weeks no one will look into / use them, so it can be
Well, we would need to have a way to determine how long to keep certain
* Faster builds (for 7-8 packages we are building, it takes ~20
to build because we do it sequentially, but we can't do anything about
that), probably some re-use of builders or faster spawning builds would
help here, not sure
We can certainly work on faster build spawning (builder reusing is already
in place). Also automatic build ordering in batch builds could also be of
here? In any case, I agree this would help a lot.
* auto-rebuilds like koschei does (but I don't really want to see
koschei as separate service, it should be built-in for better
integration). Ideally this should be in Fedora/Koji as well, but it
really depends what's COPR is aiming to do
I don't think it needs to be built-in, especially if it should serve
Well, anyway this is also something we have in mind :).
Thanks for this reply.
> Thanks in advance.
> Miroslav Suchy
> copr-devel mailing list -- copr-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to copr-devel-leave(a)lists.fedorahosted.o
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
copr-devel mailing list -- copr-devel(a)lists.fedorahosted.org
To unsubscribe send an email to copr-devel-leave(a)lists.fedorahosted.org