potiuk edited a comment on pull request #9503:
URL: https://github.com/apache/pulsar/pull/9503#issuecomment-774644408
> My understanding is, if there have multiple commits of a PR and all
commits are running the CI checks, the CI of the last commits will cancel the
previous runs. But if the CI checks are in the pending queue, the cancel
workflow will not be working, correct?
It will cancel all scheduled 'duplicate' workflows that are in "running" and
"queued" (or "pending" state).
> For example, I have a PR A has two commits C1, and C2. If the CI checks of
both C1 and C2 are pending in the queue, then it will run C1 at first and then
run C2. In this situation, it looks like the cancel workflow is not working
anymore.
Yes it will work. Just to give you a more complete (and complex) example
(also showing the reasons why you have duplicates usually).
You have several different people submitting PR1, PR2 from their forks, and
a committer pushing branch 'branch-A" directly to your repository. Imagine
that people pushed several commits in quick succession for all of those. This
usually happen when you realized that there is one more change needed or when
you iteratively work on your PR. It hp Usually it is either a "--force-push"
commit replacing the previous ones or "--fixup commit". It works the same in
both cases but this is a "natural" way people work. For example for many people
it is far easier to review whole extent of your change in GitHub (they are used
to doing PR reviews there) so they push the change as PR, review it there
themselves and realize they need one more line to be removed (and they add
--fixup and push again).
So coming back to my example. Imagine you have high strain situation. All
your PRs generated 10 or so workflows (that's how Pulsar works - produces many
workflows per PR). But let's assume we have two "real" worklfows "w1" and "w2"
and the "cancel" workflow I added "c". So initially all of the workflows
generated are in "Pending" state. assume each of the PRs has been pushed twice
- first Commit 1 (C1) and then fixup Commit 2 (C2). So all C1s are 'older'
duplicates of C2.
| | w1-C1 | w2-C1 | c-C1 | w1-C2 | w2-C2 | c-C2 |
|----------|---------|---------|---------|---------|---------|---------|
| PR1 | pending | pending | pending | pending | pending | pending |
| PR2 | pending | pending | pending | pending | pending | pending |
| branch-A | pending | pending | pending | pending | pending | pending |
Then imagine that PR1 "standard" worflows started to run for C1. So they
change state to 'running'
| | w1-C1 | w2-C1 | c-C1 | w1-C2 | w2-C2 | c-C2 |
|----------|---------|---------|---------|---------|---------|---------|
| PR1 | running | running | pending | pending | pending | pending |
| PR2 | pending | pending | pending | pending | pending | pending |
| branch-A | pending | pending | pending | pending | pending | pending |
So far so good. Then the "cancel workflow" starts running for C1 commit in
PR1.
| | w1-C1 | w2-C1 | c-C1 | w1-C2 | w2-C2 | c-C2 |
|----------|---------|---------|---------|---------|---------|---------|
| PR1 | running | running | running | pending | pending | pending |
| PR2 | pending | pending | pending | pending | pending | pending |
| branch-A | pending | pending | pending | pending | pending | pending |
The "cancel" workflow with "allDuplicates" mode is "aggressive". It will
look for ANY duplicates in ANY PRs/Branches (including the Pending ones) and
cancels them. So what happens next it will set all C1 runs to cancelled state
(no matter if they were Pending or running):
| | w1-C1 | w2-C1 | c-C1 | w1-C2 | w2-C2 | c-C2 |
|----------|---------|---------|---------|---------|---------|---------|
| PR1 | cancelling | cancelling | complete | pending | pending |
pending |
| PR2 | cancelling | cancelling | pending | pending | pending | pending
|
| branch-A | cancelling | cancelling | pending | pending | pending | pending
|
Those runs will be quickly canceled and job slots from the "Running" ones
will be freed for next runs so likely some of the Pending C2 runs from PR1 will
be quickly "Running:
| | c-C1 | w1-C2 | w2-C2 | c-C2 |
|----------|----------|---------|---------|---------|
| PR1 | complete | running | running | pending |
| PR2 | pending | pending | pending | pending |
| branch-A | pending | pending | pending | pending |
Now - the "cancel" workflows are not cancelled themselves. They will
continue running, but they are very quick usually and any "cancel workflow" run
next will see there are no duplicates and will complete quickly leaving the
"slot" for "real" workflows of the latest commits (C2) to run - hopefully more
slots are available then and your C2 workflows start running after that:
| | c-C1 | w1-C2 | w2-C2 | c-C2 |
|----------|----------|----------|----------|----------|
| PR1 | complete | complete | complete | complete |
| PR2 | complete | running | running | pending |
| branch-A | pending | pending | pending | pending |
Hower if the committer again pushes THIRD commit C3 to branch-A in the
meantime, the (so far pending) cancel workflows will again prove to be useful.
Let's say PR2's "cancel workflow" for C2 runs after the new commit has been
added by the commiyter:
| | c-C1 | w1-C2 | w2-C2 | c-C2 | w1-C3 | w2-C3 |
c-C3 |
|----------|----------|----------|----------|----------|---------|---------|---------|
| PR1 | complete | complete | complete | complete | | |
|
| PR2 | complete | complete | running | running | | |
|
| branch-A | pending | pending | pending | pending | pending | pending |
pending |
The PR2's c-C2 workflow (or even branch-As, c-C1 workflow will find that
there is a duplicate in `branch-A` and it will cancel those:
| | c-C1 | w1-C2 | w2-C2 | c-C2 | w1-C3 | w2-C3 |
c-C3 |
|----------|----------|----------|----------|----------|---------|---------|---------|
| PR1 | complete | complete | complete | complete | | |
|
| PR2 | complete | complete | complete | complete | |
| |
| branch-A | complete | cancelled | cancelled | running | running |
running | pending |
Again the "cancel" workflows complete quickly and do nothing as there are no
duplicates, freeing the slot for "regular" workflows:
| | c-C1 | w1-C2 | w2-C2 | c-C2 | w1-C3 | w2-C3 |
c-C3 |
|----------|----------|----------|----------|----------|---------|---------|---------|
| PR1 | complete | complete | complete | complete | | |
|
| PR2 | complete | complete | complete | complete | |
| |
| branch-A | complete | cancelled | cancelled | complete | running |
running | running |
Effectively what we get is that the "duplicates" will be cancelled
frequently enough (as often as ANY "cancel" workflow from ANY commit from ANY
branch manages to get into "running" state)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
