aws / aws/bedrock-agentcore-sdk-python

CI pipeline does not trigger on release PRs created by github-actions[bot]

Ouverte
#370 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
Langage dominant
Python
Étoiles
761
Forks
147
Merge moyen
1 j 23 h
PR mergées (30 j)
7

Description

## 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.

Guide de contribution

Ouvrir le guide de contribution

Piste de recherche

Commencez par lire .github/workflows/release-prepare.yml, ci.yml et pr-automerge.yml, puis suivez la façon dont le workflow de release pousse sa branche et crée la pull request. Comparez le comportement des déclencheurs des workflows et les noms des checks requis ; le travail est terminé lorsque les PR de release reçoivent tous les checks CI requis et que l’auto-merge reconnaît les checks définis par ci.yml.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
github-actions
Domaine
ci-cd, devops
Type d'issue
Bug
Difficulté
4/5
Temps estimé
3-5 jours
Activité
Calme
Clarté
Plutôt claire
Accessibilité débutants
52/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.