https://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842016-01-12T10:14:57ZopenSUSE Project Management ToolopenQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=200982016-01-12T10:14:57Zcoolocoolo@suse.com
<ul></ul><p>I would say that this a too special job to put such a prominent icon on such a prominent page. What about providing a script to do such special mass retriggers?</p>
openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=201002016-01-12T10:18:08ZRBrownSUSErbrown@suse.com
<ul></ul><p>It's not that 'special' - it happens repeatedly during the development of all SLE products and it needs to be doable by Release Managers - and we don't want to give them openQA shell access to run scripts themselves</p>
openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=201282016-01-12T12:21:54Zcoolocoolo@suse.com
<ul></ul><p>but how often is it done? once or twice every couple of weeks. how often do you see that button? every freaking day on every freaking job group.</p>
<p>And scripts don't need shell access - just as not everyong using osc rebuildpac requires shell access on OBS. Adam maintains a nice pair of python bindings</p>
openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=201502016-01-12T14:37:53Zokurzokurz@suse.com
<ul></ul><p>I would go for the python bindings to create fast prototypes of what might be useful to have as controls in the web ui later on.</p>
openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=201942016-01-13T13:11:26Zcoolocoolo@suse.com
<ul></ul><p>BTW: Ludwig has a user story that is related to this. He wants to repost a set of ISO parameters to reschedule all jobs with the new templates.</p>
openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=206302016-01-20T10:12:38ZRBrownSUSErbrown@suse.com
<ul><li><strong>Target version</strong> set to <i>Milestone 1</i></li></ul> openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=226062016-03-24T15:19:27Zoholecekoholecek@suse.com
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul><p>Rescheduling of iso is done in <a href="https://progress.opensuse.org/issues/2776" class="external">issue#2776</a><br>
The 'unobsoleting' thing seems to me can already be done by providing <code>_NOOBSOLETEBUILD</code> variable when scheduling new iso (apparently this has been already implemented). Technically this does does not do 'unobsoleting' rather it does not cancel running/scheduled tests of old iso when scheduling new one. What do you think?</p>
openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=238682016-05-30T14:03:55Zokurzokurz@suse.com
<ul></ul><p>Can't we simply disable the "obsoleting old builds" again and instead deprioritize them? It is also helpful for reviewers if the build they review is not obsoleted "under their hands" and keeping a steady history for scenarios.</p>
<p>Proposal:</p>
<ul>
<li>don't obsolete old jobs</li>
<li>on new iso: if jobs for old build are in state scheduled, set priority-10</li>
</ul>
openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=239382016-06-01T09:16:39Zokurzokurz@suse.com
<ul><li><strong>Blocked by</strong> <i><a class="issue tracker-4 status-3 priority-4 priority-default closed" href="/issues/11072">action #11072</a>: Always finish important builds</i> added</li></ul> openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=239442016-06-01T10:36:37Zcoolocoolo@suse.com
<ul></ul><p>not everything is reviewed. we have plenty of staging DVDs that never see any reviewer for example</p>
openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=239962016-06-01T12:31:13Zokurzokurz@suse.com
<ul></ul><p>rbrown and coolo do not want to disable the old build obsoletion e.g. to reduce worker load and more regarding some use cases of RMs. However, he agrees that for reproduction purposes it would make sense not to abort the according job runs (we don't know how this could be done). Preferred would be to reproduce not on the productive instance but then we have the problem of how to make workers available for multiple parties (see <a class="issue tracker-4 status-6 priority-4 priority-default closed" title="action: shared workers (Rejected)" href="https://progress.opensuse.org/issues/12194">#12194</a>).<br>
Also, we had the idea to tier tests more and do a prerequisite job in our "test pipeline", e.g. check if ISO is bootable and finish successfully and start all other jobs after that mini-test_suite.</p>
openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=241602016-06-07T11:39:16Zokurzokurz@suse.com
<ul><li><strong>Assignee</strong> set to <i>okurz</i></li></ul> openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=243282016-06-14T11:04:21Zokurzokurz@suse.com
<ul></ul><p>So "finish testing a build" is considered to be complete with <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: Always finish important builds (Resolved)" href="https://progress.opensuse.org/issues/11072">#11072</a>, regarding "retest entire build", can someone post the easy CLI approach here? Is there really a GUI way necessary? If yes, how should it look like so that coolo is also ok with that (see <a class="issue tracker-4 status-3 priority-5 priority-high3 closed" title="action: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build" (Resolved)" href="https://progress.opensuse.org/issues/9760#note-3">#9760#note-3</a>)? Maybe instruct it with an API call from some OBS dashboard?</p>
openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=243322016-06-14T11:57:03Zcoolocoolo@suse.com
<ul></ul><p>when was the last time we needed it? </p>
openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=244702016-06-17T15:47:46Zokurzokurz@suse.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul> openQA Project - action #9760: "Finish Testing a Build" (aka Un-Obsolete) and "Retest entire build"https://progress.opensuse.org/issues/9760?journal_id=244742016-06-17T15:51:20Zokurzokurz@suse.com
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li></ul><p>seems like the "retest entire build" is not really needed often or we didn't need it for a long time. In most if not all cases we need to selectively retrigger jobs because there are probably always some jobs which work in every case. As the subtask is also done we can close this.</p>