jdaugherty commented on code in PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#discussion_r3178366266
##########
.github/workflows/release-notes.yml:
##########
@@ -13,41 +13,159 @@
# See the License for the specific language governing permissions and
# limitations under the License.
+# Maintains one draft GitHub Release per active release branch (7.0.x, 7.1.x,
+# 7.2.x, 8.0.x, ...). Each branch produces an independent draft because the
+# release-drafter config in .github/release-drafter.yml combines
+# `filter-by-commitish: true`, `filter-by-range: ~MAJOR.MINOR.0`, and
+# `tag-prefix: v` so that drafts created on one branch never leak into another.
+#
+# Companion config: .github/release-drafter.yml
name: "Release - Drafter"
on:
- issues:
- types: [closed,reopened]
+ # Runs on every push to a release branch so the draft for that branch is
+ # always up to date with the latest merged PRs.
push:
branches:
- '[0-9]+.[0-9]+.x'
+ # Runs on PRs whose BASE branch is a release branch so the autolabeler can
+ # apply labels (bug/feature/docs/...) and the draft picks up new PRs as soon
+ # as they are opened. Feature-to-feature PRs (e.g. fix/foo -> feat/bar)
+ # are intentionally excluded - they cannot affect any release.
pull_request:
types: [opened, reopened, synchronize, labeled]
+ branches:
+ - '[0-9]+.[0-9]+.x'
+ # Manual recovery: rerun against any branch (e.g. to recreate a draft after
+ # one was accidentally deleted, or to seed an initial draft on a new branch).
workflow_dispatch:
-# queue jobs and only allow 1 run per branch due to the likelihood of hitting
GitHub resource limits
+
+# Per-branch concurrency. Critically: this group MUST NOT collide with the
+# `release-pipeline-${branch}` group used by .github/workflows/release.yml.
+# The release pipeline has manual approval gates (`environment: release`,
+# `environment: docs`, `environment: sdkman`) which routinely keep a release
+# run in `waiting` state for HOURS or DAYS until a maintainer approves the
+# next stage. When the drafter shared that group, every push to a release
+# branch queued behind those waiting runs - producing drafter runs of
+# 1400-2000+ minutes that ultimately got cancelled, leaving drafts stale.
+#
+# Drafter and release.yml never touch the same release object: the drafter
+# maintains a DRAFT for the *next* version (e.g. v7.0.12), while release.yml
+# uploads assets to the *current published* tag (e.g. v7.0.11). Splitting the
+# concurrency groups is therefore safe.
+#
+# `cancel-in-progress: true`: if multiple pushes land on the same branch in
+# quick succession, only the latest matters - the latest run sees every PR
+# the older one would have seen, so cancelling pending runs is correct.
concurrency:
- group: release-pipeline-${{ github.event.pull_request.base.ref ||
github.ref_name }}
- cancel-in-progress: false
+ group: release-drafter-${{ github.event.pull_request.base.ref ||
github.ref_name }}
Review Comment:
I dont' think this is correct. We want the concurrency to be shared with
the release, otherwise release drafter will modify a release that is being
released. We do not want that to ever happen.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
