Bug 1313270

Summary: Build fails when rebuilding a build and different chroots than before are selected
Product: [Community] Copr Reporter: clime
Component: frontendAssignee: Adam Samalik <asamalik>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: asamalik
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-07 12:26:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description clime 2016-03-01 09:49:18 UTC
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 13:14:18 UTC
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 13:04:23 UTC
(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 09:36:30 UTC
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 14:17:19 UTC
> 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.