Bug 1313270 - Build fails when rebuilding a build and different chroots than before are selected
Build fails when rebuilding a build and different chroots than before are sel...
Status: CLOSED NEXTRELEASE
Product: Copr
Classification: Community
Component: frontend (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Adam Samalik
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-01 04:49 EST by clime
Modified: 2016-03-08 09:17 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-07 07:26:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description clime 2016-03-01 04:49:18 EST
Build fails when rebuilding a build and different chroots than before are selected.

There is a piece of "optimization" logic that does not perform srpm import into dist-git when rebuilding. It assumes, the srpm was imported for the previous build. But that holds only if the chroots in both builds are the same.
Comment 1 Adam Samalik 2016-03-02 08:14:18 EST
This behavior makes sense when resubmitting a build of an uploaded srpm - we don't have that file anymore.

A build with new chroots should be submitted as a 'new build' instead of 'rebuild of an existing one'.
Comment 2 clime 2016-03-03 08:04:23 EST
(In reply to Adam Samalik from comment #1)
> This behavior makes sense when resubmitting a build of an uploaded srpm - we
> don't have that file anymore.

This resubmitted build was specified by an external srpm:
https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1/build/164523/

> A build with new chroots should be submitted as a 'new build' instead of
> 'rebuild of an existing one'.

This might be relevant:
Bug 1286334 - resubmit should offer other buildroots
Comment 3 Adam Samalik 2016-03-07 04:36:30 EST
So I will do it as follows:

If the source was 'upload srpm':
 - only chroots from the original build will be available
 - the new build will be submitted as 'pending' which would skip the dist git import

If the source was anything else than 'upload srpm':
 - all chroots in the project will be available
 - the new build will be submitted as 'importing'
Comment 5 clime 2016-03-08 09:17:19 EST
> If the source was 'upload srpm':
>  - only chroots from the original build will be available
>  - the new build will be submitted as 'pending' which would skip the dist

There is still a possible (though not _so_ significant) issue in the code. It might happen that import of an uploaded srpm fails (e.g. corrupted srpm or bug in copr-dist-git). If we rebuild a build with failed imports, the importing phase won't be skipped (even for an uploaded-srpm build, see logic/builds_logic.py:268). But because the original uploaded srpm is not present on frontend anymore, the import will again fail (for a different reason than before, though). Note that this issue was present even before fixing Bug 1286334 (- resubmit should offer other buildroots).

The original problem is fixed (with "selection of other chroots than before") so I won't reopen this but I think we should consider keeping the uploaded srpms on frontend server (for some time) and always (re)import. It is just the most simplistic approach.

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