RSS Bot Posted June 8 Posted June 8 Description On every PR, a workflow is started to check if artifacts should be built. This happens not only once, but many times, e.g. for every selected reviewer. Since the workflow has cancel-in-progress enabled, workflows are started and immediately cancelled by the next one, resulting in many notifications (see https://github.com/armbian/build/actions/workflows/build-artifacts-pr.yml how many of the workflows were duplicates which were cancelled). Move the cancel-in-progress concurrency policy to the second job which starts only after a check is done if the 'Build' label is even active on the PR. This should greatly reduce "Workflow cancelled" notifications via GitHub and email (if enabled by the user). Documentation that concurrency can also be used on jobs: https://docs.github.com/en/actions/using-jobs/using-concurrency#example-using-concurrency-and-the-default-behavior Also don't start the workflow on PR 'reviewer_requested' trigger. It does not need to be started every time a single reviewer is added, since requesting a review does not change the build. If the 'Build' label was already added earlier, the build workflow will have been started already. In addition, don't run shellcheck if a PR message ot title was edited since it does not change the code at all. See doc: https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=edited#pull_request How it has been tested [x] Check started workflow this PR: https://github.com/armbian/build/actions/workflows/build-artifacts-pr.yml Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code View the full article
Recommended Posts