Hi Joey,
On 2/26/24 16:41, Joey Vagedes wrote:
> Hi Lazlo,
>
> I just looked at the pipelines - Looks like everything is fine, there is just
> currently a backup of runners of jobs in the runners. It is common for jobs
> that end in CODE_COVERAGE to appear frozen in queued status, but this is
> expected as this job not queued until all others have finished, which means
> it gets put at the end of the list of pipelines to execute.
>
> Taking a look at all the runners
> (https://dev.azure.com/tianocore/edk2-ci/_settings/buildqueue?_a=concurrentJobs
> [Click "Microsoft Hosted", "View in-progress jobs"]), I don't see any
> runners that are frozen, which is why it appears it's just a backup.
>
> I'll continue to monitor.
thanks -- meanwhile I've also found the blockage, just from a different
perspective.
I've known for a while that it is not ideal to have multiple PRs open at
the same time with the "push" label set. They will either compete for
resources (slow), or one will block the other ("queued" state); however,
the main annoyance is that once the first PR gets merged, the HEAD of
the master branch will move for all the other PRs, and then those PRs
will fail to merge even if their CIs run to completion. So in such
cases, the maintainer needs to notice the problem in the first place
(possibly after having waited for 30+ minutes), then perform a manual
rebase (using the github web UI or a local rebase + force push), and
then pray that their next attempt will get to the front of the queue.
It would be much better if:
- *either* the "preempted" PRs rebased themselves automatically to the
new master HEAD, and restarted the CI + merge train,
- *or*, if at least one PR with "push" were in progress at the time of
the maintainer creating a new PR with "push", the CI run wouldn't even
*start* -- instead, the maintainer would *immediately* get information
about being blocked (and about the inevitable need to rebase later, once
that "other" -- earlier-filed -- PR completes).
Now, I've been trying to implement strategy#2 myself, by checking the
"open PRs" view (with an eye towards the "push" label among those PRs)
just before submitting a PR myself. I did that this time as well, but
didn't see any concurrent push-PR. That's why I was confused -- first I
didn't understand what blocked my CI tasks, and then I didn't understand
what had preempted (= de-synced) my PR. When I fetched locally afresh, I
found two new commits, but didn't understand where those had come from,
given that I couldn't see any push-PR concurrently to mine.
*However*, searching my edk2-devel folder for the subjects of those
suddenly appearing new commits, I figured out the problem: PR
<https://github.com/tianocore/edk2/pull/5187> was created in *December*
last year, but Liming set the "push" label on it only ~2 hours ago. In
other words, PR#5187 was the one to hold up and preempt mine. So, why
did I not see it in the "open PRs" view? (Because, as I wrote above, if
I had seen it, I wouldn't have submitted mine in the first place -- I'd
have known it would be useless, due to the master branch moving forward
anyway!)
Well the reason I didn't see PR#5187 (donning the "push" label at that)
was that PR#5187 had been *old as heck*, and so it simply didn't make
the first page of the "open PRs" listing! I didn't expect two months old
PRs to be merged.
So, my lesson from this is: it's not the plain "open PRs" view that I
need to check, when implementing approach #2 myself. Instead, I have to
explicitly search for open PRs with the "push" label:
https://github.com/tianocore/edk2/labels/push
Thanks!
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115973): https://edk2.groups.io/g/devel/message/115973
Mute This Topic: https://groups.io/mt/104510905/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
