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 1057937 - copr sometimes does not replace previous failed build mock output with more recent failed build mock output
Summary: copr sometimes does not replace previous failed build mock output with more r...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Copr
Classification: Community
Component: backend
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-26 04:09 UTC by Jens Petersen
Modified: 2015-01-21 05:30 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-21 05:30:04 UTC


Attachments (Terms of Use)

Description Jens Petersen 2014-01-26 04:09:24 UTC
Description of problem:
As far as I can tell the buildsys seems to cache uploaded srpms.
So if I respin an srpm and try to rebuild it, copr builds
the original srpm again instead of the new srpm.

I guess the upside of this is that it enforces bumping of release. ;)
But it can be kind of annoying if one doesn't want to bump.

Steps to Reproduce:
1. build srpm from url
2. update srpm with same n-v-r
3. rebuild srpm from url

Actual results:
3. original srpm gets rebuilt

Expected results:
3. new srpm to be built

Comment 1 Miroslav Suchý 2014-01-27 07:53:32 UTC
Copr does not cache srpm. But if there already exists already built same n-v-r, it will skip that build for that chroot (and e.g. build only into chroots where it previously failed).
OK. I admit that Copr can be more verbose and in status say, that some builds have been skipped - but I believe it is stated somewhere in logs.

This is behaviour is intentional. And comes from good habits, that each change in srpm should bump up release.

Unless I get response from non-trivial number of people, that this is what they want (feel free to open discussion on fedora devel mailing list), then I'm closing this as WONTFIX.

Comment 2 Jens Petersen 2014-01-28 01:10:46 UTC
(In reply to Miroslav Suchý from comment #1)
> if there already exists already built same n-v-r,
> it will skip that build for that chroot (and e.g. build only into
> chroots where it previously failed).

So if it failed in some chroot previously it will
use the newer srpm?  I see

> OK. I admit that Copr can be more verbose and in status say, that some
> builds have been skipped - but I believe it is stated somewhere in logs.

Okay I guess I missed the log message.
Yeah when it is a noop it would be more transparent
if it "said" so explicitly in the web interface perhaps.

> This behaviour is intentional. And comes from good habits, that each
> change in srpm should bump up release.

Right.

If I delete a successful build of n-v-r and then try to build
a modified srpm with same n-v-r, it will use the newer srpm?

Comment 3 Miroslav Suchý 2014-01-28 01:21:34 UTC
> If I delete a successful build of n-v-r and then try to build
> a modified srpm with same n-v-r, it will use the newer srpm?

Yes.

Comment 4 Jens Petersen 2014-02-28 03:45:31 UTC
(In reply to Jens Petersen from comment #2)
> So if it failed in some chroot previously it will
> use the newer srpm?  [..]

I think I hit this again.

1. I tried to build http://petersen.fedorapeople.org/uploads/ghc-7.8.0.20140226-30.1.fc21.src.rpm in http://copr-be.cloud.fedoraproject.org/results/petersen/ghc-7.8/
2. It failed (task 3469)
3. I respun http://petersen.fedorapeople.org/uploads/ghc-7.8.0.20140226-30.1.fc21.src.rpm to fix the preceding packaging issue.
4. It failed again in the same way (task 3474)
   implying that the former srpm was reused not the newer one.

Is that expected behaviour?

Comment 5 Miroslav Suchý 2014-02-28 15:49:39 UTC
Well this is kinda weird.

I would say that it is technically impossible. Src.rpm is downloaded to builder only. And builder is VM which is terminated right after build and for next build is taken new VM.

But I tried to reproduce it. And 
1) If I build it localy on my workstation it will fail (with different error)
error: Installed (but unpackaged) file(s) found:
   /usr/lib64/ghc-7.8.0.20140226/bin/hpc
   /usr/lib64/ghc-7.8.0.20140226/ghc-split

2) If I build it in Copr, it build successfully:
http://copr-be.cloud.fedoraproject.org/results/msuchy/foo/fedora-20-x86_64/ghc-7.8.0.20140226-30.1.fc21/

3) And because you do not bump up release I could not compare logs to previous task.

Comment 6 Jens Petersen 2014-03-03 04:08:48 UTC
Sorry I meant to comment earlier during the weekend...

I *think* now the problem is not the srpm being cached
but the mock output dirs are not getting updated after
a failure.

Anyway in the meantime I "destroyed" the evidence again
but successfully building a respun srpm.

> 3) And because you do not bump up release I could not compare logs to
> previous task.

I know but I don't want to bump release for each single tiny
little tweak I do to the spec file - it is tedious.

Koji supports this use-case well - I really wish copr would too:
cache mock output for every build task.

But I can reopen again or open a new ticket
when I see similar problem again in future: ie not being
able to see latest mock output sometimes after failed rebuild.

Comment 7 Jens Petersen 2014-04-10 08:39:46 UTC
Not sure but this might actually be a timing issue.

I think I often see considerable delays between a build
finishing or failing and the results/logs getting copied to
to the public copr directory.

Would it not be possible to build directly into
the public copr directory - then we could also
see the build.log etc live rather than only after the fact.

Comment 8 Jens Petersen 2014-04-11 03:14:09 UTC
> I think I often see considerable delays between a build
> finishing or failing and the results/logs getting copied to
> to the public copr directory.

This might be true for a successful build after a failure
but not for successive build failures like this:

http://copr-be.cloud.fedoraproject.org/results/petersen/ghc-7.8/fedora-20-x86_64/

(Note the time stamp of ghc-7.8.1-33.2.fc20/ compared to last build-*.log's.)

(Still not sure why it is failing seems to be some network/fedora mirror issue.)

> Would it not be possible to build directly into
> the public copr directory - then we could also
> see the build.log etc live rather than only after the fact.

I'd still like to see a direct results dir for every build.
Failed builds results could be removed after a week or month say.

So for above example would have:

:
ghc-7.8.1-33.2.fc20-8766/
ghc-7.8.1-33.2.fc20-8851/

etc.

Comment 9 Valentin Gologuzov 2015-01-19 17:32:31 UTC
There was no new comments, Is this bug still reproducible?

Comment 10 Jens Petersen 2015-01-21 05:30:04 UTC
I don't think I have seen anything like this recently.

Let's close it for now - I can reopen if I should see it again.


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