You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@grails.apache.org by "jamesfredley (via GitHub)" <gi...@apache.org> on 2026/05/02 15:42:27 UTC
[PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
jamesfredley opened a new pull request, #15623:
URL: https://github.com/apache/grails-core/pull/15623
## Summary
Comprehensive overhaul of the **Release - Drafter** setup that fixes a long-standing set of compounding issues across `7.0.x`, `7.1.x`, `7.2.x`, and `8.0.x`. Lands first on `7.0.x` and is intended to be merged forward into the higher branches in the usual cascade.
The drafter has been quietly broken for months. Symptoms users have hit:
- The `8.0.x` draft was never created (no draft for any branch currently exists).
- Recent runs queued for **1,400-2,000+ minutes** before being cancelled.
- Release notes occasionally bumped from stale baselines (e.g. `v7.0.10` instead of `v7.0.11`) because the latest releases were excluded from the "last release" lookup.
- `continue-on-error: true` made all of the above invisible: every run reported "success" even when it produced nothing.
This PR addresses all nine root causes in a single change so the next merge cascade gives every release branch a working drafter at once.
## Root causes and fixes
### 1. Concurrency lock with `release.yml` (the hour-long delays)
`release-notes.yml` and `release.yml` both used `release-pipeline-${branch}`. `release.yml` has manual approval gates (`environment: release`, `environment: docs`, `environment: sdkman`) which routinely keep a release run in `waiting` state for **days** until a maintainer approves the next stage. Every push to a release branch during that window queued behind the waiting release run.
Evidence from the workflow history:
| Run | Branch | Duration | Result |
|---|---|---|---|
| 25214035979 | 7.0.x | 1,400 min | cancelled |
| 25197284620 | 7.1.x-stop-4x-exceptionlogging | 2,091 min | cancelled |
| 25167124818 | 7.0.x | 1,358 min | cancelled |
**Fix:** switch to `release-drafter-${branch}` with `cancel-in-progress: true`. The drafter and `release.yml` never touch the same release object - the drafter targets the next-version *draft* (e.g. `v7.0.12`), `release.yml` the currently-published tag (e.g. `v7.0.11`) - so splitting the groups is safe.
### 2. Prereleases excluded from "last release" detection (the missing 8.0.x draft)
This is the single biggest fix and the reason no draft exists for `8.0.x`.
Every Apache Grails release - `v7.0.11`, `v7.1.1`, `v8.0.0-M1`, ... - is published on GitHub with `prerelease=true` during the ASF vote process. release-drafter's default `include-pre-releases=false` filters those out when finding the "last release", which means:
- `7.0.x` bumped from `v7.0.10` (last non-prerelease) instead of `v7.0.11`.
- `7.1.x` bumped from `v7.1.0` instead of `v7.1.1`.
- `8.0.x` had no last release at all (only `v8.0.0-M1` exists, excluded as a prerelease) - so the action fell back to walking the entire 265-release commit history and **exhausted the GitHub API rate limit** (visible verbatim in the workflow logs):
```
Found 265 releases
No draft release found
No last release found
Fetching parent commits of 8.0.x...
##[error]Request failed due to following response errors:
- API rate limit already exceeded for site ID installation.
```
Simulation of the new filter pipeline against today's release set:
| Branch | Current `lastRelease` | After fix |
|---|---|---|
| `7.0.x` | `v7.0.10` (wrong) | `v7.0.11` |
| `7.1.x` | `v7.1.0` (wrong) | `v7.1.1` |
| `7.2.x` | NONE (rate limit) | NONE (bounded by `initial-commits-since`) |
| `8.0.x` | NONE (rate limit) | `v8.0.0-M1` |
**Fix:** `include-pre-releases: true` in `.github/release-drafter.yml`.
### 3. Unbounded git history walk on rate-limit exhaustion
When no last release is found, release-drafter walks parent commit history through GraphQL, paging until the entire history is consumed.
**Fix:** `initial-commits-since: '2026-04-29T00:00:00Z'` (just before the most recent releases). This is consulted only when no last release matches the filters - so it does not affect `7.0.x`/`7.1.x`/`8.0.x` (which now find their last release thanks to fix #2), and it bounds `7.2.x`'s walk to days instead of years.
### 4. release-drafter `v7.2.0` bug
`initial-commits-since` was silently ignored when set only in `release-drafter.yml` (not also as a workflow input) - exactly the path we use. Fixed upstream in [release-drafter#1593](https://github.com/release-drafter/release-drafter/pull/1593), shipped in `v7.2.1`.
**Fix:** pin to `release-drafter@563bf132657a13ded0b01fcb723c5a58cdd824e2` (`v7.2.1`).
### 5. Floating action tag on 7.0.x
`7.0.x` used `release-drafter@v7` while `8.0.x` was already pinned to a SHA. This violates the ASF security policy enforced in #15523.
**Fix:** SHA pin on every branch via the merge cascade.
### 6. `continue-on-error` swallowed all failures silently
A transient or permanent drafter failure looked identical to a successful run; that is precisely why this broken state went unnoticed for months.
**Fix:** keep `continue-on-error` (so transient API blips do not turn every PR check red) but add an explicit verification step that:
- Logs a structured workflow summary with the draft id, tag, name, and URL on success.
- Emits a `::warning::` annotation and a workflow-summary warning when the action produced no draft id (the failure mode that made this invisible).
### 7. Workflow ran on every PR
`pull_request: types: [opened, reopened, synchronize, labeled]` matched PRs targeting any branch, including feature-to-feature PRs that can never affect a release.
**Fix:** `branches: ['[0-9]+.[0-9]+.x']` on the trigger.
### 8. `issues` trigger
Drafter has nothing to do with issue lifecycle; the trigger fired on every issue close/reopen.
**Fix:** removed.
### 9. Cross-branch leakage prevention (defense in depth)
Combine three filters so release-drafter cannot match a release from a different release line either when looking for the "last release" to bump from or for an existing draft to update:
- `filter-by-commitish: true` (release's `target_commitish` must equal the branch).
- `filter-by-range: ~MAJOR.MINOR.0` (computed dynamically from the branch name in the workflow step).
- `tag-prefix: v` (release's tag must start with `v`).
## Files changed
- `.github/release-drafter.yml`
- Added `tag-prefix: v`, `include-pre-releases: true`, `initial-commits-since`.
- Existing config (`filter-by-commitish: true`, autolabeler, categories, version-resolver, template) unchanged.
- `.github/workflows/release-notes.yml`
- Removed `issues:` trigger.
- Restricted `pull_request` trigger to release branches.
- Switched concurrency group to `release-drafter-${branch}` with `cancel-in-progress: true`.
- Pinned `release-drafter` to `v7.2.1` by commit SHA.
- Added `id: drafter` and a verification step that surfaces missing-draft failures via workflow summary and annotations.
- Heavily commented so future maintainers do not have to re-derive the rationale for any of the above.
## How to verify after merge
1. Watch the next push to `7.0.x` trigger the drafter and complete in **seconds** (no longer queued behind `release.yml`).
2. Confirm a draft release `v7.0.12` (or whatever the version-resolver picks) appears at https://github.com/apache/grails-core/releases with `target_commitish=7.0.x`.
3. After the merge cascade reaches `8.0.x`, confirm a `v8.0.0-M2` (or `v8.0.0`) draft appears with `target_commitish=8.0.x` - this is the missing draft from the original report.
4. If a draft ever fails to appear again, the workflow summary will now contain a clearly visible warning instead of silently passing.
## Out of scope
- The 9 historical `v7.0.x` releases whose `target_commitish` is `refs/heads/7.0.x` instead of `7.0.x` are benign: `find-previous-releases.ts` strips `refs/heads/` before comparing, so they still match `filter-by-commitish: true`. No cleanup needed.
- The 16 older 3.x/4.x releases with SHA `target_commitish` cannot match any current branch filter and are correctly excluded.
Assisted-by: claude-code:claude-4.6-opus
--
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
Posted by "testlens-app[bot] (via GitHub)" <gi...@apache.org>.
testlens-app[bot] commented on PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#issuecomment-4571546398
## 🔎 No tests executed 🔎
🏷️ Commit: 90c4924c8cee81b6e8609c9b51aca734a77a5d20
▶️ Tests: 0 executed
⚪️ Checks: 33/33 completed
---
_Learn more about TestLens at [testlens.app](https://testlens.app)._
--
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
Posted by "jamesfredley (via GitHub)" <gi...@apache.org>.
jamesfredley commented on PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#issuecomment-4521049110
### Follow-up: how this PR also fixes the "draft `7.0.7` while `7.0.6` is being voted on" cascade
This came up offline as a longstanding pain point with the drafter, so worth pinning it explicitly. `include-pre-releases: true` (one of the three filter changes in this PR) is the entire fix on the drafter side.
#### Why it was broken
Our ASF release flow stages every release on GitHub with `prerelease=true` for the duration of the 72-hour vote. The release-drafter default is `include-pre-releases: false`, so during the vote window the in-flight release is invisible to the action. Consequences:
- `7.1.x` and `7.0.x`: drafter would bump from the *previous* stable (e.g. `v7.0.10`), try to draft `v7.0.11`, but `v7.0.11` already existed as the in-vote prerelease. Either the draft never moved forward or it collided with the in-vote tag.
- `8.0.x`: `v8.0.0-M1` is permanently `prerelease=true` (milestone convention), so the drafter has *never* been able to see any release on `8.0.x`. That is why no `8.0.x` draft exists today.
Net effect: there was no draft for "the next version" while a vote was running, which is exactly the moment a maintainer wants to look at one.
#### Why it now works
With `include-pre-releases: true`, release-drafter sees prereleases when picking the "last release". Combined with the existing `version-resolver` (which defaults to a `patch` bump and reads `type: major / minor / patch` PR labels), the cascade is fully automatic:
```
v7.0.11 published, no in-flight vote -> drafter maintains draft v7.0.12
v7.0.12 staged (prerelease=true), vote open -> drafter sees v7.0.12 as last release
-> drafter maintains draft v7.0.13
v7.0.12 vote passes, prerelease flag dropped -> same baseline, drafter keeps maintaining v7.0.13
v7.0.12 vote fails, prerelease tag deleted -> drafter falls back to v7.0.11
-> draft becomes v7.0.12 again, automatically
```
Equivalent flow on `8.0.x`:
```
v8.0.0-M1 (prerelease=true, permanent) -> drafter maintains draft v8.0.0-M2
(or v8.0.0-RC1 / v8.0.0 with the right type: label)
```
Minor caveat on milestone branches: `semver.inc('8.0.0-M1', 'patch')` is `8.0.0` (strip prerelease, no version bump), so M1 -> M2 transitions need a PR labeled `type: minor` or the draft tag manually renamed. Once a non-milestone `8.0.x` release is cut, the cascade behaves the same as on `7.0.x`.
#### Where the existing `apache/grails-github-actions` next-version logic fits
For completeness - there *is* a "calculate the next version" script in the Apache org: [`apache/grails-github-actions/post-release/increment_version.sh`](https://github.com/apache/grails-github-actions/blob/asf/post-release/increment_version.sh) (`-M` major, `-m` minor, `-p` patch, with M/RC handling). It is invoked from `release.yml`'s `close` job *after* a successful vote, and its job is to write `${NEXT}-SNAPSHOT` into `gradle.properties` for the next dev cycle. That is a different concern from "what version should the next GitHub Release *draft* be tagged as", which is what `release-drafter` handles via `version-resolver`.
Both default to a patch bump, so they agree by default. If we ever want them to disagree (e.g. cut a minor instead of a patch), we already have two coordinated mechanisms:
- **Snapshot bump in `gradle.properties`**: override the call to `increment_version.sh` (or pass an explicit `RELEASE_VERSION` to `post-release`).
- **Draft tag in release-drafter**: label one of the merged PRs with `type: minor` (or `type: major`) so `version-resolver` picks the matching bump.
There is no need to wire `increment_version.sh` into the drafter - release-drafter already does the same computation, sourced from PR labels instead of a hard-coded flag, which is actually closer to "intelligent enough to figure out the next version" than a fixed `-p` invocation. The dilemma described offline is resolved by fix #2 in the PR description; no additional action or plugin is required.
--
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
Posted by "jdaugherty (via GitHub)" <gi...@apache.org>.
jdaugherty commented on PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#issuecomment-4366666116
> The change separates the concurrency group from 'release-pipeline-${branch}' to 'release-drafter-${branch}' to prevent drafter runs from queuing behind long-waiting release pipeline jobs with manual approvals. The comment explains drafter updates a draft for the next version (e.g., v7.0.12), while release.yml handles the current published tag (e.g., v7.0.11), so they don't conflict. Sharing concurrency isn't needed since they target different releases.
>
> **.github/workflows/release-notes.yml**
>
> ```
> concurrency:
> group: release-drafter-${{ github.event.pull_request.base.ref || github.ref_name }}
> cancel-in-progress: true
> ```
This is incorrect. The creation of the tag itself was enough to historically trigger the release drafter workflow and thus a release being performed would overlap the release drafter run too.
--
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
Posted by "matrei (via GitHub)" <gi...@apache.org>.
matrei commented on PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#issuecomment-4607081918
> @jamesfredley we 100% had it kick off with no changes other than creating the release. Remove the concurrency and create a release to see it, but this was a constant problem in our release process that I would have to immediately kill the job after push. I'm not sure why it was doing this, but nothing had actually committed other than the tag. Both @matrei & I saw this across multiple of our repos until we added the concurrency restriction.
I know there was a problem that there was another GitHub Release created, I think with the same name, and the release workflow uploaded artifacts to that wrong GitHub Release. I started disabling the the release drafter workflow when doing releases to workaround that issue.
I think we should try these changes out. Lets see what happens. I mean, look at the releases page today: https://github.com/apache/grails-core/releases
--
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
Posted by "jdaugherty (via GitHub)" <gi...@apache.org>.
jdaugherty merged PR #15623:
URL: https://github.com/apache/grails-core/pull/15623
--
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
Posted by "jamesfredley (via GitHub)" <gi...@apache.org>.
jamesfredley commented on PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#issuecomment-4521006536
@jdaugherty Pulled the workflow files and run history to verify. The specific mechanism you described - tag creation triggering the drafter - doesn't match what's in the code or the run logs, but the broader overlap concern is real, just through a different path. Receipts below.
### 1. The drafter trigger never matched tags
The pre-PR `release-notes.yml` on `7.0.x` had:
```yaml
on:
push:
branches:
- '[0-9]+.[0-9]+.x'
```
GitHub Actions' `push` event with a `branches:` filter does not fire on tag pushes - tag pushes require an explicit `tags:` clause, and there isn't one. Pushing `refs/tags/v7.0.*` alone could not trigger the drafter.
### 2. The pre-release action pushes only a tag ref, never a branch commit
`apache/grails-github-actions/pre-release@asf` (the script invoked from `release.yml`) does:
```bash
git checkout "v${VERSION}" # detached HEAD at the tag
...
git commit -m "[skip ci] Release v${VERSION}" # commit lives on detached HEAD
git tag -fa v${VERSION} ...
git push origin "v${VERSION}" --force # ONLY the tag ref is pushed
```
The commit never lands on `7.0.x`. Only the tag is force-pushed, and `[skip ci]` in the message would suppress workflows on a branch push anyway.
### 3. The three runs cited in the PR description prove it
| Run | Event | Trigger |
|---|---|---|
| 25214035979 (1,400 min) | `push` to `7.0.x` | Merge of PR #15616 (`wrapper-cli-verification`) |
| 25197284620 (2,091 min) | `pull_request` | `fix 4x exception logging` |
| 25167124818 (1,358 min) | `pull_request` | `Where Query documentation improvements` |
Zero of these are tag-creation events. All three are normal branch / PR activity that happened to land during a release window.
### Where the overlap concern is right
Drafter and `release.yml` did overlap, just not through tags. The actual path:
1. Normal PRs keep merging to `7.0.x` during the 72-hour+ ASF vote.
2. Each merge fires the drafter on `push: branches:`.
3. Meanwhile `release.yml` is parked in `waiting` state on its `environment: release / docs / sdkman` manual-approval gates.
4. Both workflows shared `release-pipeline-${branch}`, so the drafter queued behind the waiting release run for days until GitHub's 24-hour run cap killed it.
bito's framing - "they target different releases, so the concurrency group does not need to be shared" - is correct as the rationale for splitting the groups. The bug was not that drafter and `release.yml` touched the same release object (they never did); it was that the shared concurrency group held the drafter hostage to the manual-approval wait window.
--
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
Posted by "jdaugherty (via GitHub)" <gi...@apache.org>.
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
Posted by "testlens-app[bot] (via GitHub)" <gi...@apache.org>.
testlens-app[bot] commented on PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#issuecomment-4364233417
## ✅ All tests passed ✅
🏷️ Commit: d4608a4b659e9844c0d9f1e128bd6b0232290988
▶️ Tests: 31769 executed
⚪️ Checks: 37/37 completed
---
_Learn more about TestLens at [testlens.app](https://testlens.app)._
--
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
Posted by "bito-code-review[bot] (via GitHub)" <gi...@apache.org>.
bito-code-review[bot] commented on PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#issuecomment-4366571636
<!-- Bito Reply -->
The change separates the concurrency group from 'release-pipeline-${branch}' to 'release-drafter-${branch}' to prevent drafter runs from queuing behind long-waiting release pipeline jobs with manual approvals. The comment explains drafter updates a draft for the next version (e.g., v7.0.12), while release.yml handles the current published tag (e.g., v7.0.11), so they don't conflict. Sharing concurrency isn't needed since they target different releases.
**.github/workflows/release-notes.yml**
```
concurrency:
group: release-drafter-${{ github.event.pull_request.base.ref || github.ref_name }}
cancel-in-progress: true
```
--
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
Posted by "jdaugherty (via GitHub)" <gi...@apache.org>.
jdaugherty commented on PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#issuecomment-4605209473
@jamesfredley we 100% had it kick off with no changes other than creating the release. Remove the concurrency and create a release to see it, but this was a constant problem in our release process that I would have to immediately kill the job after push. I'm not sure why it was doing this, but nothing had actually committed other than the tag. Both @matrei & I saw this across multiple of our repos until we added the concurrency restriction.
--
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
Posted by "testlens-app[bot] (via GitHub)" <gi...@apache.org>.
testlens-app[bot] commented on PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#issuecomment-4521287710
## ✅ All tests passed ✅
🏷️ Commit: 182a751d58402f267db26cadfc24093818a3e617
▶️ Tests: 4187 executed
⚪️ Checks: 33/33 completed
---
_Learn more about TestLens at [testlens.app](https://testlens.app)._
--
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
Posted by "testlens-app[bot] (via GitHub)" <gi...@apache.org>.
testlens-app[bot] commented on PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#issuecomment-4570440578
## 🔎 No tests executed 🔎
🏷️ Commit: 345a86fb8ca9fc99348f94935482037f5d91806a
▶️ Tests: 0 executed
⚪️ Checks: 2/2 completed
---
_Learn more about TestLens at [testlens.app](https://testlens.app)._
--
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(ci): comprehensive overhaul of release-drafter setup [grails-core]
Posted by "testlens-app[bot] (via GitHub)" <gi...@apache.org>.
testlens-app[bot] commented on PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#issuecomment-4605984166
## ✅ All tests passed ✅
🏷️ Commit: b8707158d100a5f1eba988efebf2b8fddcb183c1
▶️ Tests: 5419 executed
⚪️ Checks: 33/33 completed
---
_Learn more about TestLens at [testlens.app](https://testlens.app)._
--
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: notifications-unsubscribe@grails.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org