Paul Nothaft
3ca6378bd7
After the org move + branch rename (#669): beta → main (active development) main → stable (curated release channel) This PR rewires the workflows that referenced the old branch names so release-please and the Docker build target the right channels. ## Workflow changes ### `.github/workflows/docker-build.yml` - **Push triggers**: `[main, beta]` → `[main, stable]` (both `push.branches` and `pull_request.branches`). `beta` no longer exists; `stable` is the curated channel that should also produce builds. - **`is_prerelease` detection**: pre-release context was decided by `refs/heads/beta`; now decided by `refs/heads/main` (active dev → prerelease, `-beta.N` version suffix unchanged). - **`:latest` + `:stable` tagging**: were gated on `{{is_default_branch}}` (which used to be `main` = stable channel). Default branch is now `main` = active dev, so the implicit gate would have aliased `:latest` to dev. Both tags now explicitly gate on `refs/heads/stable` OR a non-prerelease release tag. - **`:beta` tag**: REMOVED. Active-dev pulls are `:main` (auto-generated by `type=ref,event=branch`). The pre-rename `:beta` tag remains frozen at its last build under Option B / #669 — operators are expected to update to `:main` or pin to a versioned tag. ### `.github/workflows/release-please.yml` - `branches: [main]` → `branches: [stable]`. This is the **stable** release-please workflow (uses `release-please-config.json`); after the rename, the stable channel lives on the `stable` branch. ### `.github/workflows/release-please-beta.yml` - `branches: [beta]` → `branches: [main]`. - `target-branch: beta` → `target-branch: main`. - This is the **pre-release** release-please workflow (uses `release-please-config-beta.json`, `prerelease: true`); after the rename, pre-releases are cut from the new `main` (active dev). The version-suffix scheme stays `-beta.N` so existing operator pins keep working. ## RELEASING.md Rewrote the TL;DR, "How a stable release is cut", and hotfix path to reference the new branch names. Added a one-line "branch model background" note pointing at #669 so future maintainers know why `main` means active dev (the opposite of what some projects use). Filename conventions: `release/X.Y.Z-merge-from-main` (was `…-from-beta`); promotion PR title `promote main → stable as vX.Y.Z` (was `promote beta → main`). ## Why combined with PR A's content as a single PR Originally planned as two PRs (B = workflow triggers, C = release-please reconfigure). Splitting wasn't worth it: the configs are branch-agnostic (`release-please-config.json` and `release-please-config-beta.json` don't mention branch names internally), and not bundling them meant a window where the stable release-please workflow would fire on pushes to the new `main` (active dev) — exactly the wrong place. Single PR closes that gap. ## Versioning scheme — kept No version-scheme decision needed. The `-beta.N` suffix on pre-release versions is preserved (existing operator pins like `v3.71.3-beta.0` keep working). If a `v4.0.0-pre.N`-style reset is desired later, that's a separate PR with explicit operator-comms attached.
37 lines
1.3 KiB
YAML
37 lines
1.3 KiB
YAML
name: Release Please
|
|
|
|
on:
|
|
push:
|
|
branches: [stable]
|
|
|
|
permissions:
|
|
contents: write
|
|
pull-requests: write
|
|
|
|
jobs:
|
|
release-please:
|
|
runs-on: ubuntu-latest
|
|
outputs:
|
|
release_created: ${{ steps.release.outputs.release_created }}
|
|
tag_name: ${{ steps.release.outputs.tag_name }}
|
|
version: ${{ steps.release.outputs.major }}.${{ steps.release.outputs.minor }}.${{ steps.release.outputs.patch }}
|
|
steps:
|
|
- name: Run Release Please
|
|
uses: googleapis/release-please-action@v4
|
|
id: release
|
|
with:
|
|
token: ${{ secrets.GITHUB_TOKEN }}
|
|
config-file: release-please-config.json
|
|
manifest-file: .release-please-manifest.json
|
|
|
|
- name: Output Release Info
|
|
if: ${{ steps.release.outputs.release_created }}
|
|
run: |
|
|
echo "## Release Created! " >> $GITHUB_STEP_SUMMARY
|
|
echo "" >> $GITHUB_STEP_SUMMARY
|
|
echo "**Tag:** ${{ steps.release.outputs.tag_name }}" >> $GITHUB_STEP_SUMMARY
|
|
echo "**Version:** ${{ steps.release.outputs.major }}.${{ steps.release.outputs.minor }}.${{ steps.release.outputs.patch }}" >> $GITHUB_STEP_SUMMARY
|
|
echo "" >> $GITHUB_STEP_SUMMARY
|
|
echo "Docker images will be built and tagged with this version." >> $GITHUB_STEP_SUMMARY
|
|
|