Repository navigation
fix(tutorials): retry flaky PyPI fetches in pydantic_ai images (#547) #7
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| name: Release Please | |
| # Hand-edited from the stlc-generated template. `.github/workflows/*.yml` is | |
| # scaffold-once, so this survives every later build -- upstream's own source cites | |
| # exactly this PAT-to-App swap as the reason that preservation exists. Do NOT run | |
| # `stlc build --rewrite-scaffold` without reapplying the changes below. | |
| # | |
| # What changed from the generated file, and why each is load-bearing: | |
| # | |
| # 1. A token minted from a dedicated release App instead of | |
| # `secrets.RELEASE_PLEASE_TOKEN`, which does not exist and which we do not want | |
| # to create -- eliminating PATs was the point of the App migration. It is | |
| # deliberately NOT the codegen App, so the codegen App's key does not have to | |
| # live on the production repos. Nor is it `GITHUB_TOKEN`: releases created by | |
| # GITHUB_TOKEN do not trigger other workflows, so publish-*.yml would never | |
| # fire and the release would stop one hop short of the registry. | |
| # | |
| # 2. The release-please CLI (`npx`, exact version) instead of | |
| # googleapis/release-please-action. scale-agentex-typescript sets | |
| # `allowed_actions: selected` and does not permit that action; the CLI needs | |
| # only actions/-owned steps, which `github_owned_allowed: true` covers on both | |
| # production repos. | |
| # | |
| # 3. `issues: write` on the minted token. release-please drives its | |
| # autorelease:pending -> autorelease:tagged labels through the Issues API. | |
| # Without it you get duplicate release pull requests. The generated file omits | |
| # it, and the omission is silent until it bites. | |
| # | |
| # 4. `environment: release` on the job. That environment holds the release App's | |
| # key and deploys from main only. GitHub creates any environment a job names | |
| # that does not exist yet, with no protection, so a typo in the name silently | |
| # creates an unprotected environment. | |
| # | |
| # 5. `github-release` runs before `release-pr` (the release-please-action order). | |
| # A release-pr failure, such as the workflows refusal below, then cannot stop a | |
| # merged release PR from being tagged and published. In the other order | |
| # release-pr skips the run while a merged release is still untagged ("untagged, | |
| # merged release PRs outstanding"), so the next release PR waits for another push. | |
| # | |
| # The release App has no `workflows` permission. If release-please reports "refusing | |
| # to allow a GitHub App to create or update workflow", close the release PR and | |
| # delete its branch, then re-run this workflow (or wait for the next push to main); | |
| # it opens the release PR again from main. | |
| # | |
| # Requires, on the PRODUCTION repo (a workflow only reads secrets from the repo it | |
| # runs in, and the guard below means that is production): | |
| # - the secret AGENTEX_RELEASE_APP_PRIVATE_KEY in the environment `release` | |
| # - the repository variable AGENTEX_RELEASE_APP_ID | |
| # - the release App installed on this repo (contents, pull requests and issues: write) | |
| on: | |
| push: | |
| branches: | |
| - main | |
| workflow_dispatch: | |
| permissions: | |
| contents: read | |
| # One run at a time, so two quick pushes cannot race to open duplicate release PRs or | |
| # cut the same release twice. A running job is never cancelled; a newer push replaces | |
| # a still-queued run, which is harmless because release-please reads live repo state. | |
| concurrency: | |
| group: release-please | |
| cancel-in-progress: false | |
| jobs: | |
| release-please: | |
| # Self-routing: this file is SHA-identical on the staging trunk, where it must | |
| # stay inert. Only production cuts releases. | |
| if: github.repository == 'scaleapi/scale-agentex-python' | |
| runs-on: ubuntu-latest | |
| # See 4 above. Keep this name identical to the provisioned environment, and give | |
| # it no required reviewers: a reviewer there would hold every push to main. | |
| environment: release | |
| steps: | |
| - name: Mint release token | |
| id: release-token | |
| uses: actions/create-github-app-token@v2 | |
| with: | |
| app-id: ${{ vars.AGENTEX_RELEASE_APP_ID }} | |
| private-key: ${{ secrets.AGENTEX_RELEASE_APP_PRIVATE_KEY }} | |
| owner: scaleapi | |
| repositories: scale-agentex-python | |
| permission-contents: write | |
| permission-pull-requests: write | |
| permission-issues: write | |
| permission-metadata: read | |
| - uses: actions/setup-node@v4 | |
| with: | |
| node-version: '20' | |
| - name: GitHub release + release PR | |
| env: | |
| RP_TOKEN: ${{ steps.release-token.outputs.token }} | |
| run: | | |
| # github-release turns an already-merged release PR into the tag + GitHub | |
| # Release that publish-pypi.yml / publish-npm.yml trigger on; release-pr then | |
| # opens or updates the next version-bump pull request. Both are idempotent, | |
| # so running the pair on every push carries a release the whole way, and a | |
| # release-pr failure cannot stop a merged release from being tagged. | |
| # | |
| # No checkout step is needed: release-please reads the config and manifest | |
| # from the repo over the API. | |
| npx --yes release-please@16.18.0 github-release \ | |
| --token="$RP_TOKEN" --repo-url="${{ github.repository }}" \ | |
| --config-file=release-please-config.json \ | |
| --manifest-file=.release-please-manifest.json | |
| npx --yes release-please@16.18.0 release-pr \ | |
| --token="$RP_TOKEN" --repo-url="${{ github.repository }}" \ | |
| --config-file=release-please-config.json \ | |
| --manifest-file=.release-please-manifest.json |