Skip to content

chore(main): release 6.8.0 - #460

Merged
agustincelentano merged 2 commits into
mainfrom
release-please--branches--main
Aug 3, 2026
Merged

chore(main): release 6.8.0#460
agustincelentano merged 2 commits into
mainfrom
release-please--branches--main

Conversation

@github-actions

@github-actions github-actions Bot commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

🤖 I have created a release beep boop

6.8.0 (2026-08-03)

Features

  • scope_definition: read action list from service spec by default (#458) (3695dbe)

This PR was generated with Release Please. See documentation.

@agustincelentano
agustincelentano merged commit 9bc5d8a into main Aug 3, 2026
1 check passed
@agustincelentano
agustincelentano deleted the release-please--branches--main branch August 3, 2026 15:09
@github-actions

github-actions Bot commented Aug 3, 2026

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