Skip to content

ci: adopt release-please for release management - #834

Open
lilustga wants to merge 3 commits into
mainfrom
user/lilustga/release-strategy
Open

ci: adopt release-please for release management#834
lilustga wants to merge 3 commits into
mainfrom
user/lilustga/release-strategy

Conversation

@lilustga

Copy link
Copy Markdown
Collaborator

What this PR does / why we need it:

Replaces Akri's manual, checklist-driven release process with an automated pipeline built around Conventional Commits and release-please. release-please maintains a "Release PR" that bumps the version, regenerates the changelog, tags, and creates the GitHub Release — which triggers the existing container/Helm publish workflows unchanged.

Included:

  • release-please-config.json + .release-please-manifest.jsonsimple release type (keeps version.txt canonical), pre-1.0 bump flags, Keep-a-Changelog sections, extra-files to propagate the version into Cargo.toml and Chart.yaml.
  • .github/workflows/release-please.yml — opens/updates the Release PR and tags + publishes on merge, using a GitHub App token (required so release: published fires the downstream pipelines).
  • .github/workflows/version-guard.yml — blocks manual edits to version.txt/Cargo.toml version/Chart.yaml/CHANGELOG.md (release-please PRs exempt).
  • .github/workflows/conventional-pr-title.yml — enforces Conventional Commit PR titles.
  • .github/workflows/release-notes-agent.md — optional gh-aw agent that drafts release notes on the Release PR (read-only, comment-only).
  • Retired check-versioning.yml and update-versions.yml; dropped the manual version bump from auto-update-dependencies.yml; updated the PR template.
  • Docs under docs/development/: strategy, backlog/open-questions, agentic-workflow, and a first-run checklist.

Special notes for your reviewer:

Before this pipeline can cut a release (safe to merge the scaffolding first — it's inert until then):

  • Create the "Akri Release Bot" GitHub App and set RELEASE_APP_ID / RELEASE_APP_PRIVATE_KEY secrets.
  • Update branch protection to require Version guard / guard and Conventional PR title / lint-title (drop the old check-versioning).
  • Validate the first Release PR diff — especially Cargo.lock (the simple type may not bump the 14 workspace-crate entries; see docs/development/release-first-run-checklist.md). If it does, switch to rust type + cargo-workspace plugin.
  • v0.13.26 is already tagged, so the first changelog starts cleanly from there.

If applicable:

  • this PR contains documentation (docs/development/)
  • this PR contains unit tests
  • added code adheres to standard Rust formatting (cargo fmt) — n/a, no Rust changes
  • code builds properly (cargo build) — n/a, no code changes
  • all commits pass the DCO bot check by being signed off

- add release-please config, manifest, and workflow (simple type, GitHub App token)
- add version-guard workflow to block manual version/changelog edits
- add conventional-pr-title check to enforce Conventional Commit titles
- add release-notes-agent (gh-aw) to draft notes on the Release PR
- retire check-versioning.yml and update-versions.yml
- drop manual version bump from auto-update-dependencies
- update PR template for the new flow
- add release strategy, backlog, agentic-workflow, and first-run-checklist docs

Signed-off-by: lilustga <lilustga@microsoft.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR introduces an automated release-management approach for Akri using Conventional Commits + release-please, replacing the previous manual version-bump/checklist workflows while preserving existing publish triggers from GitHub Releases. It also adds CI guards to prevent manual drift of version/changelog files and documents the rollout strategy and first-run validation steps.

Changes:

  • Add release-please configuration + workflow to maintain a Release PR and publish releases via a GitHub App token.
  • Add new CI gates: Conventional Commit PR-title enforcement and a “version/changelog drift” guard; retire old versioning workflows.
  • Add development documentation covering the release strategy, rollout checklist, backlog, and optional agentic release-notes workflow.

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
release-please-config.json Adds release-please config using simple release type and extra-files version propagation.
docs/development/release-strategy.md New RFC-style doc describing the intended end-to-end release workflow and rollout plan.
docs/development/release-first-run-checklist.md New checklist for validating the first Release PR and publish fan-out.
docs/development/release-backlog.md New backlog of open decisions/risks and follow-up policy work.
docs/development/release-agentic-workflow.md Documents an optional read-only AI-assisted release-notes drafting flow.
.release-please-manifest.json Bootstraps release-please manifest with the current version.
.github/workflows/release-please.yml New workflow to open/update Release PRs and publish releases using a GitHub App token.
.github/workflows/version-guard.yml New workflow blocking manual edits to version/changelog-owned files (exempts release-please branches).
.github/workflows/conventional-pr-title.yml New workflow enforcing Conventional Commit PR titles.
.github/workflows/release-notes-agent.md Adds gh-aw source for an optional release-notes drafting agent workflow.
.github/workflows/auto-update-dependencies.yml Removes the old automated version bump from the dependency update workflow.
.github/workflows/check-versioning.yml Removes the old version-change enforcement workflow.
.github/workflows/update-versions.yml Removes the old /version comment-driven bump workflow.
.github/pull_request_template.md Updates PR template guidance to align with Conventional Commits + release-please ownership of versions/changelog.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread docs/development/release-strategy.md Outdated
Comment on lines +205 to +207
- **Releasable units**: release-please only opens/updates a Release PR when it sees
`feat`, `fix`, or `deps` commits since the last release; `chore`/`build`/`ci` alone won't
trigger a release (they still appear in the changelog).

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch — this is a real contradiction. chore/build/ci are marked hidden: true in changelog-sections, so they won't appear in the generated changelog. Fixed the wording in §6 to say they don't trigger a release and don't appear in the changelog.

Comment thread docs/development/release-strategy.md
Comment on lines +23 to +26
"extra-files": [
{ "type": "toml", "path": "Cargo.toml", "jsonpath": "$.workspace.package.version" },
{ "type": "yaml", "path": "deployment/helm/Chart.yaml", "jsonpath": "$.version" },
{ "type": "yaml", "path": "deployment/helm/Chart.yaml", "jsonpath": "$.appVersion" }

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Valid and important — this is the known #1 risk of the simple release type. release-please bumps Cargo.toml via extra-files but will not update the 14 workspace-crate versions in Cargo.lock, so the first Release PR would produce a tagged commit where the two disagree and cargo build --locked fails.

It's deliberately left as-is in this scaffolding PR (which is inert until the GitHub App is configured) rather than guessed at, because the fix — release-type: rust + the cargo-workspace plugin — depends on how release-please handles Akri's virtual workspace.package.version, which needs validation. That's the #1 Phase-1 spike item (strategy §5.1), and the guardrail is docs/development/release-first-run-checklist.md §2, which requires confirming Cargo.lock in the first Release PR before merging. Added an explicit ⚠️ note to §7.1 as well. If preferred, I can switch to rust + cargo-workspace in a follow-up once validated.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in f0a1a0c. Rather than release-type: rust + cargo-workspace (which doesn't cleanly support Akri's version.workspace = true inheritance), I added .github/workflows/release-please-lockfile.yml: on the Release PR it runs cargo update --workspace and commits the refreshed Cargo.lock back to the branch, so the tagged commit keeps Cargo.toml/Cargo.lock in sync. It pushes with the App token (so the --locked CI re-runs) and signs off the commit for DCO. Verified cargo update --workspace is workspace-scoped (cargo 1.95: "Only update the workspace packages").

lilustga added 2 commits July 21, 2026 07:37
…mitted release-please-config

Addresses Copilot review on PR #834:
- clarify that hidden types (chore/build/ci) do not appear in the changelog
- match the §7.1 example to the committed config (drop tag-separator + cargo-workspace)
- add a Cargo.lock desync note to §7.1

Signed-off-by: lilustga <lilustga@microsoft.com>
release-type: simple bumps the workspace version in Cargo.toml via extra-files but
does not update the workspace-member versions in Cargo.lock, so the tagged release
commit would desync and break --locked builds.

- add release-please-lockfile.yml: runs 'cargo update --workspace' on the Release PR
  and commits the refreshed Cargo.lock (App token so CI re-runs; --signoff for DCO)
- chosen over release-type: rust + cargo-workspace, which does not cleanly support
  Akri's 'version.workspace = true' inheritance
- update release-strategy §7.1 and the first-run checklist to reference the workflow

Signed-off-by: lilustga <lilustga@microsoft.com>
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.

2 participants