t; Hi,
>
> Last time I checked, it was possible to cancel a build from copr client
AFAIK it is only possible to cancel builds that haven't been started yet.
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/copr-devel
On 09/20/2016 11:33 AM, Michal Novotny wrote:
> - mock build configs are now available in the result directories (under
> ./configs)
Great! That made it possible for me to debug an issue related to custom
chroots. Proposed fix submitted as
https://github.com/fedora-copr/copr/pull/15
--
M
URLs in all the places where I
use them.
What would happen with builds? For me the idea of re-running them, in
correct order, re-bootstrapping, fixing FTBFS etc. sounds a lot like
asking users to move away from Copr to something else (or switch to
using custom-1 chroot with rawhide
hat his package doesn't build anymore.
Sounds like you are asking for Koschei for Copr.
We are working on first bits of integration right now.
See: https://github.com/msimacek/koschei/issues/113
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
__
some dependency changed).
Since there are no scratch builds in Copr, "testing builds" need to be
simulated by building in separate Copr project, with appropriate repos
added and createrepo disabled. Doing "real builds" is almost the same
thi
On 10/11/2016 08:17 AM, Pavel Raiskup wrote:
> On Tuesday, October 11, 2016 8:11:16 AM CEST Mikolaj Izdebski wrote:
>> Since there are no scratch builds in Copr, "testing builds" need to be
>> simulated by building in separate Copr project, with appropriate repos
>>
> There will be no need to rebuild any existing builds.
Do you mean that builds from f26 chroot be imported to f27 when it gets
created, and so on?
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
___
copr-devel mailing list -- copr-d
ne
> like happens with Fedora packages.
1. Set up your own git repository (for example on Github) with spec
2. Add package to Copr project
3. Select the source type - "Mock SCM" and configure it
4. From now on you can run builds using copr-cli
5. Optionally you can set up Githu
koji really does some log analysis, I'd love to review "backport"
> pull-request of the same logic. Or at least fill an issue.
The logic used by Koji is simple: if mock exits with status code 1
then it's "build.log". Ot
