Skip to content

Add end-to-end release automation#80

Open
dwoz wants to merge 2 commits into
mainfrom
add-release-automation
Open

Add end-to-end release automation#80
dwoz wants to merge 2 commits into
mainfrom
add-release-automation

Conversation

@dwoz

@dwoz dwoz commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

Replaces #78 with a fully automated docs-release pipeline.

Trigger

  • schedule: every 10 minutes
  • workflow_dispatch: optional salt_version override

What it does

  1. Detect the latest saltstack/salt release tag (or use the override input)
  2. Skip if .0 — LTS bumps require manual edits to lifecycle dates, downloads, etc.
  3. If no PR/branch already exists for topic/release/<version>:
    • Open the branch, rename the default key in tools/supported-versions.json (e.g. "3008.0""3008.1")
    • Commit Update to Salt <version>, push, open PR
  4. Wait for required PR checks
  5. Merge the PR
  6. Push annotated tag (minor-bumped from latest, e.g. v1.33v1.34.0) with message "v<version> release". Idempotent — skipped if tag already exists. The existing build-sphinx-docs.yml then builds on tag push.

Concurrency / idempotency

  • concurrency.group: release-automation serializes overlapping runs.
  • Existing-PR lookup, existing-tag check, and merged-state check make re-runs no-ops once a release is done.

Known caveats

  • PRs created via GITHUB_TOKEN do not trigger pull_request workflows. If you have PR-level CI you want to run before merge, replace GH_TOKEN: ${{ github.token }} in the PR-creation step with a PAT or GitHub App token stored as a secret.
  • Branch protection on main that requires reviews or status checks will block the workflow from merging — needs configuration aligned with the bot identity used.

dwoz added 2 commits June 15, 2026 13:41
Detects new Salt point releases (polling saltstack/salt every 10 min),
opens a topic/release/<version> PR with generated edits, waits for
required PR checks, merges, and runs per-repo post-merge actions.
The previous tag-push step only checked whether the *next* computed tag
name existed, which fails after success: latest=v1.34.0, next=v1.35.0,
which doesn't exist, so we'd push v1.35.0 every poll. The repo's tag
annotation convention ("v<salt_version> release") is the canonical
end-state marker. Gate wait/merge/tag-push on it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant