ci: dispatch event to create-swarm-app when released#1157
Conversation
|
slapec93
force-pushed
the
ci/set-up-ci-for-an-automatic-pr-when-a-new-bee-js-version-is-out
branch
from
0094b25 to
6a13658
Compare
darkobas2
left a comment
darkobas2
left a comment
There was a problem hiding this comment.
One nit on the trigger filter:
on:
release:
types: [published]This fires on pre-releases and drafts too — so RC tags will dispatch into create-swarm-app and open auto-bump PRs against unstable versions. If that's not desired, gate the job:
jobs:
dispatch:
if: github.event.release.prerelease == false && github.event.release.draft == falseArchitecture (App + dispatch + scoped token) looks good. The bigger concerns are on the receiver side (#13).
|
Heads up — the org already has the App's identifiers + key stored as organization secrets, no need to provision new repo-level ones:
Update the workflow to reference those instead of - uses: actions/create-github-app-token@v1
with:
app-id: ${{ secrets.BEE_RUNNER_CLIENT_ID }}
private-key: ${{ secrets.BEE_RUNNER_KEY }}
repositories: create-swarm-appOne less secret to provision per consuming repo. |
…w-bee-js-version-is-out
darkobas2
left a comment
darkobas2
left a comment
There was a problem hiding this comment.
Dispatch flow itself looks good — prerelease/draft gate is in, App token is scoped to create-swarm-app only, event_type matches the receiver. Two notes:
1. Coverage refactor: gh run list should filter by status
RUN_ID=$(gh run list --branch master --workflow tests.yaml --limit 1 --json databaseId --jq '.[0].databaseId')--limit 1 returns the most recent master run regardless of outcome. If master is failing or in progress when a PR runs, you either get no artifact (silent skip via continue-on-error) or you compare against a partial/broken run. Add a status filter:
RUN_ID=$(gh run list --branch master --workflow tests.yaml --status success --limit 1 --json databaseId --jq '.[0].databaseId')Also worth a guard for the empty case — if there's no successful master run yet (e.g. right after this merges, before master has produced an artifact), RUN_ID is empty and the download step fails. The continue-on-error: true + outcome == 'success' gate covers that without breaking the workflow, but a one-line if [ -z "$RUN_ID" ]; then exit 0; fi makes the intent explicit.
2. Two unrelated changes in one PR
The dispatch-release workflow and the tests.yaml coverage refactor are independent features touching different parts of CI. Splitting them would make git bisect and revert cleaner if either turns out to misbehave. Not blocking — just a nudge for next time.
LGTM once the master-coverage status filter is in. Architecture (App + dispatch + scoped token) is solid.
darkobas2
left a comment
darkobas2
left a comment
There was a problem hiding this comment.
dispatch-release.yml — ✅ looks good
- Filtering on
release.prerelease == false && release.draft == falseplus the receiver's semver regex validation gives two layers of defense before any sed runs. repositories: create-swarm-appcorrectly scopes the App token to a single repo.tag_name.replace(/^v/, '')handles bothv1.2.3and1.2.3tag styles.
One small edge case: a maintainer who forgets to tick "this is a prerelease" but tags it v1.2.3-rc.1 would still dispatch. The receiver's regex (^X.Y.Z(-…)?$) accepts that, so an RC could open a PR. Probably fine in practice — just worth being aware of. If you want to be stricter, gate dispatch on !contains(github.event.release.tag_name, '-').
tests.yaml — scope + a couple of small risks
- 🟡 Scope creep: the coverage-comparison refactor is unrelated to the dispatch feature. Splitting it into its own PR would make both easier to revert if one regresses.
- 🟡
gh run list --limit 1doesn't filter by status: it'll happily return an in-progress or failed master run whose artifact was never uploaded. Thecontinue-on-error+outcome == 'success'guard on the download step makes this degrade gracefully, but you'd silently lose coverage comparison until the next green master. Suggest--status success(and possibly--status completed) to pick the latest run that actually has an artifact:gh run list --branch master --workflow tests.yaml --status success --limit 1 --json databaseId --jq '.[0].databaseId' - 🟢 The new
coverage-comparisoninvocation drops two positional args (master,head_ref) — assumingnpxie coverage-comparisonwas updated to take(repo, before-summary-path, after-summary-path, pr#, token), that's fine; otherwise it'll fail at runtime. Worth confirming against the tool's current signature.
Nit
- The dispatch workflow itself doesn't need
permissions:since it only uses the App token, but adding an explicitpermissions: {}(deny-all for GITHUB_TOKEN) is a nice belt-and-suspenders.
3 participants
When we release a new version, dispatch an event to
create-swarm-apprepository, so it opens a PR to bump Bee.js version to latest