Skip to content

ci(release): migrate to shared release workflow - #13

Merged
donk8r merged 2 commits into
masterfrom
ci/workflow-path
Jun 11, 2026
Merged

ci(release): migrate to shared release workflow#13
donk8r merged 2 commits into
masterfrom
ci/workflow-path

Conversation

@donk8r

@donk8r donk8r commented Jun 11, 2026

Copy link
Copy Markdown
Member

No description provided.

@github-actions

Copy link
Copy Markdown

Octomind — developer:brief (octohub:glm)

📦 Brief: Migrate release workflow to shared reusable workflow

Overall risk: 🟡 MEDIUM · Cards: 2

# Change Risk Confidence
1 Release job replaced with external reusable workflow — release behavior now depends on muvon/ci-workflow 🟡 ●●○
2 Tag trigger narrowed to semver; artifact names simplified; homebrew version source changed 🟡 ●●●
Card 1/2: Release job delegated to external reusable workflow · 🟡 · ●●○

INTENT
Consolidate release logic into a shared reusable workflow (muvon/ci-workflow) to avoid duplicating release steps across repos.

WHAT CHANGED

  • The entire inline release job (download artifacts → compute checksums → create GitHub Release with softprops/action-gh-release@v2 using CHANGELOG.md body) is replaced by a single uses: muvon/ci-workflow/.github/workflows/release.yml@master call with artifacts: 'release-*' and draft: false
  • The if: startsWith(github.ref, 'refs/tags/') guard on the release job was removed (redundant given the tag trigger, but the reusable workflow may have its own conditions)
  • The CHANGELOG.md body path and checksums.txt generation are no longer defined in this repo — they live in the external workflow

IMPACT RADIUS

  • notify-homebrew job now reads needs.release.outputs.version instead of github.ref_name — this output must be exposed by the reusable workflow or the Homebrew tap dispatch sends an empty version
  • Release notes content and format are now controlled externally — if the reusable workflow doesn't read CHANGELOG.md, releases will have empty bodies

RISK
🟡 MEDIUM. Two dependencies on the external reusable workflow that cannot be verified from this diff alone:

  1. needs.release.outputs.version — if the reusable workflow doesn't expose a version output, the Homebrew tap notification dispatches with an empty client_payload.version, breaking automated Homebrew updates
  2. Release body content — previously CHANGELOG.md; now undefined in this repo. If the shared workflow doesn't include it, GitHub releases will have no release notes

QUESTIONS
Does muvon/ci-workflow/.github/workflows/release.yml@master expose a version output and include CHANGELOG.md as the release body?

DIVERGENCE
🧩 Incomplete change — The notify-homebrew job depends on an output (version) from a reusable workflow whose contract is not visible in this diff. This is a coupling point that will silently fail (empty version string) if the reusable workflow doesn't define it.

📎 Source

Card 2/2: Tag trigger narrowed to semver; artifact naming simplified · 🟡 · ●●●

INTENT
Tighten the tag trigger to only fire on semver-versioned tags and simplify artifact naming to work with the shared release workflow's glob pattern.

WHAT CHANGED

  • Tag trigger changed from * (matches any tag) to [0-9]+.[0-9]+.[0-9]+* (semver only — e.g. 0.1.0, 1.2.3-beta)
  • Artifact names changed from Octoweb-<version>-<arch>-apple-darwin to release-<arch> (version stripped, prefix standardized for the reusable workflow's artifacts: 'release-*' glob)
  • Added if-no-files-found: error to artifact upload — build fails loudly if the archive is missing instead of silently uploading nothing

IMPACT RADIUS

  • Non-semver tags (e.g. test, v1, rc1) will no longer trigger the release workflow — this is intentional tightening
  • Artifact names no longer contain the version string — any external process that relied on the old naming pattern (Octoweb-0.1.0-aarch64-apple-darwin) will break

RISK
🟡 MEDIUM. The semver tag pattern [0-9]+.[0-9]+.[0-9]+* does NOT match tags with a v prefix (e.g. v0.1.0). If the repo's tagging convention uses v-prefixed tags, the workflow will never trigger. The pattern matches 0.1.0 but not v0.1.0.

QUESTIONS
Is the tagging convention 0.1.0 (no v prefix)? If tags are pushed as v0.1.0, this workflow will never fire.

📎 Source

📂 Files changed (1 file, ~40 lines)
  • .github/workflows/release.yml — GitHub Actions release workflow: tag trigger, build matrix, artifact upload, release creation, Homebrew notification

{tokens:147839,cost:0.15534320000000001}

@donk8r
donk8r merged commit f9fd4c2 into master Jun 11, 2026
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