potiuk opened a new pull request #9503:
URL: https://github.com/apache/pulsar/pull/9503
The previous way of canceling workflow runs was flawed because
it was run as part of `pull_request` workflows - which did not
work for fork PRs. The reason is, that `pull_request` workflows
are executed with "read-only" `GITHUB_TOKEN`. Therefore running
the action within the PR ends with 'resource not accessible by
integration` error.
This PR implements cancel action in the way that it was intended:
the 'cancel-workflow-run' action runs within a `workflow_run`
triggered workflow which has two characteristics:
* it runs only using master version of workflow (so this workflow
will become active only after we merge it to master)
* it runs using 'write' GITHUB_TOKEN - this allows actually to
cancel the workflows withot the 'resource...' error.
In order to optimise a number of machines/jobs started, there is
only one 'CI - Cancel duplicate workflows' workflow, which
has one job with many steps - each steps cancels duplicates in a
different workflow. This `workflow_run` is triggered by the
`CI - Unit` workflow, which has been somewhat arbitrary chosen - but
this could be any of the workflows that runs with every PR.
Runing this as a single workflow/job has several benefits:
* only one job is started and takes less of the queue
* one machine is initialized once for all steps thus the overhead
of creating machine is much smaller
* splitting workflows to separate steps has the benefit of seeing
each cancelling action separately
The reason why it is done as copy&paste rather than matrix or
yaml anchor are simple:
* matrix creates sepearate job for each matrix entry - increasing
the job queue as well as adding overhead of machine creation
* Github Action does not support yaml anchors
All the `cancel` actions run with `allDuplicates` cancel mode
which causes them to agressively kill all duplicates even in
high-strain queu case - the first of the cancel jobs that starts
running will activelly kill all the duplicates of all the
workflows from all PRs running in the repository.
<!--
### Contribution Checklist
- Name the pull request in the form "[Issue XYZ][component] Title of the
pull request", where *XYZ* should be replaced by the actual issue number.
Skip *Issue XYZ* if there is no associated github issue for this pull
request.
Skip *component* if you are unsure about which is the best component.
E.g. `[docs] Fix typo in produce method`.
- Fill out the template below to describe the changes contributed by the
pull request. That will give reviewers the context they need to do the review.
- Each pull request should address only one issue, not mix up code from
multiple issues.
- Each commit in the pull request has a meaningful commit message
- Once all items of the checklist are addressed, remove the above text and
this checklist, leaving only the filled out template below.
**(The sections below can be removed for hotfixes of typos)**
-->
*(If this PR fixes a github issue, please add `Fixes #<xyz>`.)*
Fixes #<xyz>
*(or if this PR is one task of a github issue, please add `Master Issue:
#<xyz>` to link to the master issue.)*
Master Issue: #<xyz>
### Motivation
*Explain here the context, and why you're making that change. What is the
problem you're trying to solve.*
### Modifications
*Describe the modifications you've done.*
### Verifying this change
- [ ] Make sure that the change passes the CI checks.
*(Please pick either of the following options)*
This change is a trivial rework / code cleanup without any test coverage.
*(or)*
This change is already covered by existing tests, such as *(please describe
tests)*.
*(or)*
This change added tests and can be verified as follows:
*(example:)*
- *Added integration tests for end-to-end deployment with large payloads
(10MB)*
- *Extended integration test for recovery after broker failure*
### Does this pull request potentially affect one of the following parts:
*If `yes` was chosen, please highlight the changes*
- Dependencies (does it add or upgrade a dependency): (yes / no)
- The public API: (yes / no)
- The schema: (yes / no / don't know)
- The default values of configurations: (yes / no)
- The wire protocol: (yes / no)
- The rest endpoints: (yes / no)
- The admin cli options: (yes / no)
- Anything that affects deployment: (yes / no / don't know)
### Documentation
- Does this pull request introduce a new feature? (yes / no)
- If yes, how is the feature documented? (not applicable / docs / JavaDocs
/ not documented)
- If a feature is not applicable for documentation, explain why?
- If a feature is not documented yet in this PR, please create a followup
issue for adding the documentation
----------------------------------------------------------------
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]
