aws / aws/bedrock-agentcore-sdk-python
CI pipeline does not trigger on release PRs created by github-actions[bot]
- Lingua principale
- Python
- Stelle
- 761
- Fork
- 147
- Merge medio
- 1g 23h
- PR unite (30g)
- 7
Descrizione
## Problem
Release PRs (e.g. #369) created by the `release-prepare.yml` workflow never get their CI checks (`ci.yml`) triggered. This blocks merging because the `main-status-checks` ruleset requires 10 status checks to pass:
- Lint and Format
- Test Python 3.10, 3.11, 3.12, 3.13
- Build Distribution
- Test Package Installation (3.10, 3.11, 3.12, 3.13)
## Root Cause
`release-prepare.yml` uses the default `GITHUB_TOKEN` to push the release branch and create the PR. GitHub intentionally does **not** trigger workflows from events created by `GITHUB_TOKEN` to prevent infinite loops. Since the branch push and PR creation come from `github-actions[bot]`, the `pull_request` event for `ci.yml` is silently skipped.
References:
- https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow
## Secondary Issue
`pr-automerge.yml` checks for CI job names that don't match the actual names in `ci.yml`:
| pr-automerge.yml expects | ci.yml actual |
|---|---|
| `Lint` | `Lint and Format` |
| `Build Package` | `Build Distribution` |
Even if CI ran, the auto-merge would fail to find the correct check runs.
## Proposed Fix
### Option A: GitHub App token (recommended)
Use [`actions/create-github-app-token`](https://github.com/actions/create-github-app-token) in `release-prepare.yml` to generate a token from a GitHub App. Tokens from GitHub Apps **do** trigger downstream workflows.
```yaml
- name: Generate token
id: app-token
uses: actions/create-github-app-token@v1
with:
app-id: ${{ secrets.APP_ID }}
private-key: ${{ secrets.APP_PRIVATE_KEY }}
```
Then use that token for the `git push` and `gh pr create` steps. This requires:
1. Creating a GitHub App with `contents: write` and `pull-requests: write` permissions
2. Installing it on the repo
3. Adding `APP_ID` and `APP_PRIVATE_KEY` as repo secrets
### Option B: Explicitly trigger CI (quick fix, no new secrets)
Add a step at the end of `release-prepare.yml` to manually trigger the CI workflow on the release branch:
```yaml
- name: Trigger CI on release branch
env:
GH_TOKEN: ${{ github.token }}
run: |
gh workflow run ci.yml --ref "release/v$NEW_VERSION"
```
This is simpler but is a workaround rather than a proper fix.
### Fix the name mismatch in pr-automerge.yml
Regardless of which option above is chosen, update the `requiredChecks` array in `pr-automerge.yml`:
```diff
const requiredChecks = [
- 'Lint',
+ 'Lint and Format',
'Test Python 3.10',
'Test Python 3.11',
'Test Python 3.12',
'Test Python 3.13',
- 'Build Package'
+ 'Build Distribution',
+ 'Test Package Installation (3.10)',
+ 'Test Package Installation (3.11)',
+ 'Test Package Installation (3.12)',
+ 'Test Package Installation (3.13)',
];
```
## Impact
Every release PR is affected. Currently requires manual intervention (pushing an empty commit or closing/reopening the PR) to trigger CI.
Guida per i contributori
Apri la guida per i contributori
Direzione di ricerca
Inizia leggendo .github/workflows/release-prepare.yml, ci.yml e pr-automerge.yml, quindi segui il modo in cui il workflow di release esegue il push del proprio branch e crea la pull request. Confronta il comportamento dei trigger dei workflow e i nomi dei check richiesti; il lavoro è completato quando le PR di release ricevono tutti i check CI richiesti e auto-merge riconosce i check definiti da ci.yml.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- github-actions
- Ambito
- ci-cd, devops
- Tipo di issue
- Bug
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Tranquilla
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 52/100