diff --git a/.github/workflows/release.yaml b/.github/workflows/release.yaml index 9943bcddd..707de26f8 100644 --- a/.github/workflows/release.yaml +++ b/.github/workflows/release.yaml @@ -3,10 +3,19 @@ name: Release # Builds the frontend, attaches it to a GitHub release, and dispatches a # lab-backend release embedding this version. # -# Run manually (workflow_dispatch) to cut the next release from master, or -# publish a release by hand and the release event picks up from there. +# Every master push cuts the next patch release automatically (put +# '[skip release]' in the commit message to opt out). workflow_dispatch +# does the same with a selectable bump, and publishing a release by hand +# enters at the build step. on: + push: + branches: + - master + paths-ignore: + - '**.md' + - '.github/**' + - '.claude/**' release: types: [published] workflow_dispatch: @@ -31,6 +40,7 @@ concurrency: jobs: release: name: Build and Publish Release + if: github.event_name != 'push' || !contains(github.event.head_commit.message, '[skip release]') runs-on: ubuntu-latest steps: - name: Checkout @@ -54,6 +64,7 @@ jobs: else VERSION="${LATEST_TAG#v}" IFS='.' read -r major minor patch <<< "$VERSION" + # inputs.bump is empty on push events, falling through to patch. case "${{ inputs.bump }}" in major) NEW_VERSION="$((major + 1)).0.0" ;; minor) NEW_VERSION="${major}.$((minor + 1)).0" ;; @@ -107,7 +118,7 @@ jobs: # Assets are uploaded, so lab-backend can now cut a release that # embeds this frontend version. - name: Trigger lab-backend release - if: github.event_name == 'workflow_dispatch' || !github.event.release.prerelease + if: github.event_name != 'release' || !github.event.release.prerelease uses: peter-evans/repository-dispatch@28959ce8df70de7be546dd1250a005dd32156697 # v4.0.1 with: token: ${{ secrets.EPOBOT_TOKEN }} diff --git a/RELEASING.md b/RELEASING.md index 3460510a4..cc01b3057 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -2,15 +2,17 @@ ## Stable release -Run the [Release workflow](../../actions/workflows/release.yaml) (or `gh workflow run release.yaml`), picking a `patch`/`minor`/`major` bump. Everything else is automatic: +Every push to `master` cuts the next patch release automatically (except pushes that only touch markdown, `.github/`, or `.claude/` files). Each release: -1. The workflow computes the next `vX.Y.Z` tag and publishes a GitHub release from `master`. -2. It builds the frontend and attaches `lab-.tar.gz` / `lab-.zip` to the release. -3. It then dispatches a `frontend-release` event to [lab-backend](https://github.com/ethpandaops/lab-backend), which tags its own next release and builds Docker images embedding this exact frontend version. +1. Computes the next `vX.Y.Z` tag and publishes a GitHub release from the pushed commit. +2. Builds the frontend and attaches `lab-.tar.gz` / `lab-.zip` to the release. +3. Dispatches a `frontend-release` event to [lab-backend](https://github.com/ethpandaops/lab-backend), which tags its own next release and builds Docker images embedding this exact frontend version. End to end this takes ~10 minutes; the lab-backend release notes and `/lab-backend/version` output record which frontend tag was embedded. -Publishing a release by hand through the GitHub UI also works — the release publish event runs the same workflow from step 2 onwards. +Include `[skip release]` in the commit message (or squash-merge PR title) to opt a push out. + +For a `minor`/`major` bump, run the [Release workflow](../../actions/workflows/release.yaml) manually (or `gh workflow run release.yaml -f bump=minor`). Publishing a release by hand through the GitHub UI also works — the release publish event runs the same workflow from step 2 onwards. Deploying the resulting image is still a manual bump of `image.tag` in the [platform](https://github.com/ethpandaops/platform) lab application values.