Skip to content

chore(main): release 6.7.2 - #457

Merged
sebastiancorrea81 merged 2 commits into
mainfrom
release-please--branches--main
Jul 30, 2026
Merged

chore(main): release 6.7.2#457
sebastiancorrea81 merged 2 commits into
mainfrom
release-please--branches--main

Conversation

@github-actions

@github-actions github-actions Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

🤖 I have created a release beep boop

6.7.2 (2026-07-30)

Bug Fixes

  • allow gateway egress to additional VPC CIDR blocks (#452) (c6a9f3a)
  • use pull_request trigger with per-PR concurrency instead of workflow_run (#455) (6475fb6)

This PR was generated with Release Please. See documentation.

@github-actions
github-actions Bot force-pushed the release-please--branches--main branch from 2bbfa17 to a473c54 Compare July 30, 2026 13:08
@sebastiancorrea81
sebastiancorrea81 merged commit 2c66a1e into main Jul 30, 2026
44 of 45 checks passed
@sebastiancorrea81
sebastiancorrea81 deleted the release-please--branches--main branch July 30, 2026 13:20
@github-actions

Copy link
Copy Markdown
Contributor Author

🤖 Created releases:

🌻

sebastiancorrea81 added a commit that referenced this pull request Aug 7, 2026
…ll_request (#479)

## Problem

`auto-merge-release-pr` (triggered on `pull_request`) has been silently
broken for a while: the release-please PR is always opened by
`github-actions[bot]`, whose `author_association` on this repo is
`CONTRIBUTOR` (not `MEMBER`/`COLLABORATOR`). That's enough for GitHub's
"require approval for outside collaborators" gate to treat its
`pull_request`-triggered runs as needing manual approval — the same
mechanism used for fork PRs — even though this branch
(`release-please--branches--main`) lives in this repo, not a fork.

Evidence:
- Every recent release PR (#472/6.8.2, #464/6.8.1, #460/6.8.0,
#457/6.7.2, #453/6.7.1) was merged **by a human**, never by the bot.
- The last two `auto-merge-release-pr` runs on PR #476 (release 6.9.0)
completed with conclusion `action_required` and **zero jobs executed**.
- An earlier run on the same branch was stuck `queued` for >21h and
never ran.

## Fix

Switch the trigger from `pull_request` to `workflow_run` (on `"Release
Please"` completing). Runs triggered by `workflow_run` always use the
workflow file from the default branch with full permissions and aren't
subject to the outside-collaborator approval gate.

Since `workflow_run` doesn't carry PR context, a new `find-pr` job
resolves the open release PR itself (same lookup `generate-readmes`
already does in `release.yml`) and validates its author/label before
merging — this is exactly what the reusable workflow's existing
`pr_number` input was already built for (see its description in
`nullplatform/actions-nullplatform`), so **no changes needed there**.

This also removes the `concurrency`/`cancel-in-progress` workaround for
the `generate-readmes` follow-up commit race — `workflow_run` only fires
once the entire "Release Please" run (both jobs) has finished, so
there's nothing to race against anymore.

## Test plan

- [ ] Merge this PR.
- [ ] Merge (or wait for) the next normal feature/fix PR to `main`.
- [ ] Confirm in the Actions tab that `auto-merge-release-pr` now fires
via `workflow_run`, `find-pr` resolves the release PR, and `automerge`
completes successfully (no `action_required`/`queued`).
- [ ] Confirm the release PR gets merged by the bot without human
intervention, and the tag/GitHub Release is published automatically.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant