From d87803b7428dd56ef7f120c2ee853728ef812eaa Mon Sep 17 00:00:00 2001
From: Paul Meyer <49727155+katexochen@users.noreply.github.com>
Date: Tue, 21 May 2024 10:38:47 +0200
Subject: [PATCH] check-by-name: remove concurrency group

Due to the trigger on PR edit, every change to the PR body will trigger
a re-run of the check-by-name workflow. This is needed to catch of the
base branch. However, an action like ticking the checkbox of a PR will
also trigger a re-run. Furthermore, due to the concurrency group, any
already running check-by-name workflow will be canceled, leading to
a notification sent to the PR author.

To reduce the noise, remove the concurrency group. As a consequence,
multiple runs will run to completion on the same PR/commit. While
concurrent runs are often canceled after a few seconds, the workflow
will take about a minute to complete.

Signed-off-by: Paul Meyer <49727155+katexochen@users.noreply.github.com>
---
 .github/workflows/check-by-name.yml | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/.github/workflows/check-by-name.yml b/.github/workflows/check-by-name.yml
index e857c88f746d..ce7802f4aa8e 100644
--- a/.github/workflows/check-by-name.yml
+++ b/.github/workflows/check-by-name.yml
@@ -14,16 +14,16 @@ on:
     # While `edited` is also triggered when the PR title/body is changed,
     # this PR action is fairly quick, and PR's don't get edited that often,
     # so it shouldn't be a problem
+    # There is a feature request for adding a `base_changed` event:
+    # https://github.com/orgs/community/discussions/35058
     types: [opened, synchronize, reopened, edited]
 
 permissions: {}
 
-# Create a check-by-name concurrency group based on the pull request number. if
-# an event triggers a run on the same PR while a previous run is still in
-# progress, the previous run will be canceled and the new one will start.
-concurrency:
-  group: check-by-name-${{ github.event.pull_request.number }}
-  cancel-in-progress: true
+# We don't use a concurrency group here, because the action is triggered quite often (due to the PR edit
+# trigger), and contributers would get notified on any canceled run.
+# There is a feature request for supressing notifications on concurrency-canceled runs:
+# https://github.com/orgs/community/discussions/13015
 
 jobs:
   check: