ci(release): stop wiping latest release assets on .github-only pushes

[yaroslavmokflmg]

Problem

The latest pre-release had zero uploaded assets, so the client download URL returned 404 and the Fleet agent could not install on feature environments:

https://github.com/flamingo-stack/fleet/releases/download/latest/fleet-macos-universal.tar.gz -> 404

Versioned releases were fine — 0.4.11, 0.4.10 and 0.4.9 each carry both client assets. Only the rolling latest tag was affected. Tenant manifests are not involved: fleet.client.fleetTag: "latest" in openframe-saas-tenant is unchanged and valid.

Root cause

Three defects in release.yml combine:

1. .github/** is commented out in paths-ignore (since 01a6bb8, 2026-01-28), so every merge from the Flamingo Code Documentation and Flamingo Code Review bots triggers Fleet Release. Those bots started merging into main around 2026-09-10, which matches the breakage window — 0.4.11 (2026-09-08) still has its assets.

2. The release job condition !failure() && !cancelled() accepts skipped. With no server/client/helm changes, Build Fleet, Build Client and Build Helm Chart are skipped by the path filter, but Create Release still runs, deletes latest with --cleanup-tag and recreates it empty. Recent runs finish in ~45s (run 35295742772).

3. The fallback that re-attaches assets from the previous latest never worked: Prepare release artifacts has no GH_TOKEN, so gh release download fails with could not find any host configurations, the error is swallowed by || true, and the step logs total 0.

The release body is generated unconditionally, so the notes advertise client artifacts that are not attached.

Changes

• Restore .github/** in paths-ignore so bot-only pushes no longer trigger a release.
• Require at least one successful build job before Create Release runs.
• Add GH_TOKEN to Prepare release artifacts so client assets carry over when only the server or the chart changed.

Verification

• Run 35295742772: Build Client, Build Fleet, Build Helm Chart all skipped, Create Release success in 45s.
• Job log of Prepare release artifacts: could not find any host configurations, then total 0.
• gh api repos/flamingo-stack/fleet/releases/tags/latest --jq '.assets|length' returned 0 before the manual restore noted below.

Note

To unblock feature environments before this lands, the two client assets from 0.4.11 were uploaded manually to the latest release. They are replaced by pipeline output on the next push that touches ./orbit or go.mod.

[github-actions]

🦩 Flamingo Code Review

2 finding(s) — 1 action required · 1 recommended · 0 informational

Mode: advisory · Rules cited: MESHAGEN-010-2 · 1 defect(s) outside any rule

Inline comments: 2 new

---

Need another pass? Commits pushed after this review are not reviewed automatically.

• Review the new commits — the commits added since this review
• Review the whole diff again — ignoring what was already reviewed

Prefer typing? Comment @flamingo-review, or @flamingo-review full. To review every push on this pull request, add the flamingo-review-always label.

React 👍/👎 on inline comments to teach the reviewer.

Started 2026-09-18 02:35 UTC · updated 2026-09-18 02:35 UTC · workflow run

[github-actions]

🦩 🔴 [error/action_required] MESHAGEN-010-2 Release job now runs on push to main without a workflow_dispatch gate

The release job creates the actual GitHub Release (via gh release ... logic further down) and is triggered by the push event on main (see the on: block, lines 15-20) as well as workflow_dispatch. The PR's change to the if: condition only adds a check on upstream job results (needs.build.result == 'success' etc.) but does not restrict execution to github.event_name == 'workflow_dispatch'. Per rule MESHAGEN-010-2, GitHub Release creation must only be triggered by workflow_dispatch, never by push alone — this rule explicitly warns against automatic releases on push. Combined with re-enabling .github/** as a trigger path (previously commented out), this materially increases the chance that ordinary merges to main auto-publish a release. The if: condition should also require github.event_name == 'workflow_dispatch'.

Evidence

    if: >-
      !failure() && !cancelled() &&
      (needs.build.result == 'success' ||
      needs.build_client.result == 'success' ||
      needs.build_helm.result == 'success')

📝 Committable suggestion

Suggested change

	if: >-
	!failure() && !cancelled() &&
	(needs.build.result == 'success' ||
	needs.build_client.result == 'success' ||
	needs.build_helm.result == 'success')
	if: >-
	github.event_name == 'workflow_dispatch' &&
	!failure() && !cancelled() &&
	(needs.build.result == 'success' ||
	needs.build_client.result == 'success' ||
	needs.build_helm.result == 'success')

🤖 Prompt for AI agents

In .github/workflows/release.yml around lines 230-234, address this code-review finding: Release job now runs on push to main without a workflow_dispatch gate.
The `release` job creates the actual GitHub Release (via `gh release ...` logic further down) and is triggered by the `push` event on `main` (see the `on:` block, lines 15-20) as well as `workflow_dispatch`. The PR's change to the `if:` condition only adds a check on upstream job results (`needs.build.result == 'success'` etc.) but does not restrict execution to `github.event_name == 'workflow_dispatch'`. Per rule MESHAGEN-010-2, GitHub Release creation must only be triggered by workflow_dispatch, never by push alone — this rule explicitly warns against automatic releases on push. Combined with re-enabling `.github/**` as a trigger path (previously commented out), this materially increases the chance that ordinary merges to main auto-publish a release. The `if:` condition should also require `github.event_name == 'workflow_dispatch'`.
The flagged code:
```
    if: >-
      !failure() && !cancelled() &&
      (needs.build.result == 'success' ||
      needs.build_client.result == 'success' ||
      needs.build_helm.result == 'success')
```
A suggested replacement for the flagged range:
    if: >-
      github.event_name == 'workflow_dispatch' &&
      !failure() && !cancelled() &&
      (needs.build.result == 'success' ||
      needs.build_client.result == 'success' ||
      needs.build_helm.result == 'success')
Make the minimal change that resolves the finding; do not refactor unrelated code.

confidence: 55 — react 👍/👎 to teach the reviewer

[github-actions]

🦩 🟠 [warn/recommended] Re-enabling '.github/**' as a release trigger path re-introduces build-on-workflow-change risk

The diff reverts the previously commented-out - '.github/**' line under paths-ignore, meaning pushes that only touch workflow files under .github/ will no longer be ignored and will now trigger the release workflow on push to main. Combined with the release job's push-triggered execution (see companion finding), this means routine workflow-file edits merged to main can now trigger a real release job. If this re-enablement is intentional it should be called out in the PR description; otherwise it silently expands the release workflow's trigger surface.

Evidence

      - '.github/**'

🤖 Prompt for AI agents

In .github/workflows/release.yml around line 19, address this code-review finding: Re-enabling '.github/**' as a release trigger path re-introduces build-on-workflow-change risk.
The diff reverts the previously commented-out `- '.github/**'` line under `paths-ignore`, meaning pushes that only touch workflow files under `.github/` will no longer be ignored and will now trigger the release workflow on push to main. Combined with the `release` job's push-triggered execution (see companion finding), this means routine workflow-file edits merged to main can now trigger a real release job. If this re-enablement is intentional it should be called out in the PR description; otherwise it silently expands the release workflow's trigger surface.
The flagged code:
```
      - '.github/**'
```
Make the minimal change that resolves the finding; do not refactor unrelated code.

confidence: 40 — react 👍/👎 to teach the reviewer