Bug 1421728
| Summary: | Resubmit does not work for "running" builds | ||
|---|---|---|---|
| Product: | [Community] Copr | Reporter: | Pavel Raiskup <praiskup> |
| Component: | frontend | Assignee: | clime |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | unspecified | CC: | clime, jkadlcik, msuchy, praiskup |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1368458 | Environment: | |
| Last Closed: | 2018-03-02 05:50:44 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: | |
| Embargoed: | |||
| Bug Depends On: | 1368458 | ||
| Bug Blocks: | |||
|
Description
Pavel Raiskup
2017-02-13 14:36:36 UTC
Per report from Kamil Dudka. (In reply to Pavel Raiskup from comment #0) > If at least one chroot is still in "running" state, builds for "failed" > chroots may not be re-submitted because the 'build.repeatable' returns > False. > > +++ This bug was initially created as a clone of Bug #1368458 +++ > [snip] > --- Additional comment from on 2017-01-11 14:08:04 CET --- > > For the time being, the action of resubmitting is forbidden for forked > projects. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Seems like not only forked projects are now blocked for re-submits. > I'm cloning the original bug report because this is directly related > regression. Please, can you explain how this is related regression and how it depends on 1421728? (In reply to clime from comment #2) > Please, can you explain how this is related regression and how it depends on > 1421728? Sorry, the chunk I was talking about is actually innocent (I ended up the analysis too early): frontend/coprs_frontend/coprs/models.py (def repeatable): - StatusEnum("running"), ] + StatusEnum("running"), + StatusEnum("forked")] I'll have a look once more. I am quite sure that I was able to resubmit partially failed builds before (neat thing), and it was not possible now. Perhaps this is because of bug 1196826 .. and fix b924147bde8a5? (In reply to Pavel Raiskup from comment #3) > (In reply to clime from comment #2) > > Please, can you explain how this is related regression and how it depends on > > 1421728? > > Sorry, the chunk I was talking about is actually innocent (I ended up the > analysis too early): > frontend/coprs_frontend/coprs/models.py (def repeatable): > - StatusEnum("running"), ] > + StatusEnum("running"), > + StatusEnum("forked")] > > I'll have a look once more. I am quite sure that I was able to resubmit > partially failed builds before (neat thing), and it was not possible now. > > Perhaps this is because of bug 1196826 .. and fix b924147bde8a5? This is related. Note, however, that if we wanted to be precise, we would need to say that resubmitting is not allowed if some chroot is still in 'importing' state. Also, actually, this currently only applies to srpm builds that take the input from dist-git on resubmitting. I would probably suggest an alternative of package rebuilding in 'Packages' tab. (In reply to clime from comment #4) > This is related. Note, however, that if we wanted to be precise, we would > need to say that resubmitting is not allowed if some chroot is still in > 'importing' state. You mean by definition, not by the current code? Yes, we should not allow re-submit when something is in "importing" state... (also we should fix the bug 1384609 so the "importing" state is a bit faster and "atomic"). > Also, actually, this currently only applies to srpm > builds that take the input from dist-git on resubmitting. Shouldn't all (already imported) builds be resubmitted only from dist-git? > I would probably suggest an alternative of package rebuilding in 'Packages' > tab. This issue was observed during srpm-upload build with about 1.5 GB payload. I'm not sure package rebuild would help here. What would be(In reply to Pavel Raiskup from comment #5) > (In reply to clime from comment #4) > > This is related. Note, however, that if we wanted to be precise, we would > > need to say that resubmitting is not allowed if some chroot is still in > > 'importing' state. > > You mean by definition, not by the current code? Yes, we should not allow > re-submit when something is in "importing" state... (also we should fix > the bug 1384609 so the "importing" state is a bit faster and "atomic"). Yes, by definition. > > > Also, actually, this currently only applies to srpm > > builds that take the input from dist-git on resubmitting. > > Shouldn't all (already imported) builds be resubmitted only from dist-git? > I would expect it. At the moment, however, builds of other type go again through the importing stage. > > I would probably suggest an alternative of package rebuilding in 'Packages' > > tab. > > This issue was observed during srpm-upload build with about 1.5 GB payload. > I'm not sure package rebuild would help here. Not directly answering this but (srpm) builds should be repeatable as long as they are imported. So that can be fixed. All other build types can be resubmitted immediately at the moment. It now works for running builds if the srpm has been built already. New COPR version has been released. |