Skip to content

ci: stopgap — switch release workflow to workflow_dispatch only#268

Merged
ChrisonSimtian merged 1 commit into
mainfrom
chore/disable-auto-release-stopgap
May 29, 2026
Merged

ci: stopgap — switch release workflow to workflow_dispatch only#268
ChrisonSimtian merged 1 commit into
mainfrom
chore/disable-auto-release-stopgap

Conversation

@ChrisonSimtian

@ChrisonSimtian ChrisonSimtian commented May 29, 2026

Copy link
Copy Markdown
Collaborator

Why

Auto-publish on every push to main has been firing a Fallout.* release on every merge — ~20 patch versions accumulated in recent days for what was mostly internal cleanup (license-header strip, AGENTS.md doc updates, the Fallout.Core extraction commits). Every release generates a Dependabot upgrade PR in every downstream consumer repo, every morning. That's recurring fan-out pain across the entire userbase, paid by them, for changes that are mostly invisible to them.

This stopgap stops the noise today. The proper restructure — tag-triggered publishes on release/vN branches with multi-channel CD via GitHub Environments — lands as the rest of milestone #13 (driven by RFC #267).

What

  • .github/workflows/release.yml trigger changed from push: branches: main to workflow_dispatch: with an optional ref input (defaults to main; will be release/v11 once cut).
  • Header comment in the workflow file explains the stopgap and links the milestone/RFC.
  • CHANGELOG entry under [Unreleased] — 11.0 → ### Process.

What this changes operationally

  • Releases no longer happen automatically on merge. Auto-versioning via Nerdbank.GitVersioning still computes a version every commit, but nothing publishes.
  • To cut a release manually: Actions → release workflow → "Run workflow" → pick the ref. The job runs identically to before (dotnet fallout Test Pack Publish + the Nuke.* shim push to GH Packages).
  • CHANGELOG entries continue to land per the PR-creation flow as normal — they accumulate under [Unreleased] — 11.0 and ship whenever a release is manually triggered.
  • Other CI (ubuntu-latest, windows-latest, macos-latest) is unchanged — PR validation and post-merge validation still run as before.

What does NOT change

  • Versioning math: NB.GV still computes versions.
  • Test/Pack pipeline: identical run, just gated on manual trigger.
  • The Fallout.* package surface, contents, or quality.

Test plan

  • Workflow YAML parses (no syntax errors).
  • Header comment is honest about being a stopgap and links RFC: Release-branch model & multi-channel CD (tag-triggered, GitHub Environments) #267.
  • CI green on this PR (only ubuntu-latest should run since we don't touch source code).
  • After merge: confirm no release fires automatically on the next subsequent merge to main.
  • After merge: confirm "Run workflow" button is visible in Actions UI on the release workflow.

🤖 Generated with Claude Code

@ChrisonSimtian @claude
ci: stopgap — switch release workflow to workflow_dispatch only (#267)
6b0758c 
Auto-publish on every push to main has been firing a Fallout.* release on
every merge — about 20 patch versions in recent days for what was mostly
internal cleanup (license-header strip, doc updates, etc). That generates a
Dependabot upgrade PR in every downstream consumer repo, every morning.

The proper restructure (tag-triggered publishes on release/vN branches with
three GitHub Environments — nuget-org / github-packages / github-releases)
is tracked under milestone #13 / RFC #267. Until that lands, this stopgap
disables the auto-trigger and switches the release workflow to manual
workflow_dispatch only.

What changes for maintainers:
- Releases no longer happen automatically on merge to main.
- To cut a release: Actions → "release" → "Run workflow" → pick the ref.
- Cherry-pick + tag flow on release/vN branches arrives with the full
  restructure under #13.

What changes for consumers: dependabot stops screaming.

Refs #267, milestone #13.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@ChrisonSimtian
ChrisonSimtian merged commit 4b19a8c into main May 29, 2026
2 checks passed
@ChrisonSimtian
ChrisonSimtian deleted the chore/disable-auto-release-stopgap branch May 29, 2026 03:33
This was referenced May 29, 2026
Closed
Closed
Merged
ChrisonSimtian added a commit that referenced this pull request May 29, 2026
@ChrisonSimtian @claude
docs(agents): release-branch model + branch-protection policy for rel…
5e7b853 
…ease/vN (#270) (#278)

Updates docs/agents/release-and-versioning.md to reflect the new branching
model now that release/v11 has been cut (#269) and the auto-publish stopgap
landed (#268).

Branching section:
- main is now the integration trunk (PRs target here), no longer auto-publishes
- release/vN is the release channel per major (release/v11 exists; release/v12
  will follow when v12 ships)
- Hotfix flow noted as "cherry-pick from main"
- Stale "No release/* branches" line removed

New "Branch protection on release/vN" subsection captures the policy that
gets applied to every release/vN at cut time:
- Required ubuntu-latest status check
- Linear history
- CODEOWNER review required
- Stale-approval dismissal
- Direct pushes / force-pushes / deletions blocked
- Conversation resolution required
- Admins can bypass in emergencies

Release pipeline section updated to acknowledge the workflow_dispatch
stopgap and reference the pending tag-triggered shape under #274, and the
NUGET_API_KEY move-to-environment-secret under #273.

Closes #270 (the API-level branch protection on release/v11 was already
applied; this PR is the documentation half of the acceptance criteria).

Refs milestone #13, RFC #267.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@ChrisonSimtian ChrisonSimtian mentioned this pull request May 29, 2026
Merged
4 tasks
ChrisonSimtian added a commit that referenced this pull request May 29, 2026
@ChrisonSimtian @claude
ci: tag-triggered + multi-channel fan-out for release.yml (#274) (#288)
b9b2a43 
Refactors .github/workflows/release.yml from the workflow_dispatch-only
stopgap (#268) into the proper release-branch model shape per RFC #267
and milestone #13.

## Trigger

- push: tags 'v*' is the primary trigger. The new validate-ref job
  verifies the tag is reachable from a release/v* branch and fails fast
  otherwise.
- workflow_dispatch with a required `tag` input remains as a fallback
  for re-runs after a transient API failure. --skip-duplicate on each
  publish step keeps re-runs idempotent.

## Job graph

  validate-ref (skipped on workflow_dispatch)
      ↓
  test-and-pack (Test + Pack via `dotnet fallout`, uploads
                 output/packages/*.nupkg as Actions artifact)
      ↓ ↓ ↓  (fan-out)
  publish-nuget-org       (env: nuget-org,       Fallout.*.nupkg → nuget.org,    gated)
  publish-github-packages (env: github-packages, Nuke.*.nupkg → GH Packages,    unguarded)
  publish-github-releases (env: github-releases, all *.nupkg → GH Release,      unguarded)

Each publish job declares `environment:` so a per-channel deployment
record appears under the Deployments tab. The nuget-org env requires
approval (set in #272); the other two are unguarded.

## Channel routing

- nuget.org gets ONLY Fallout.* — Nuke.* shim IDs belong to the
  original NUKE maintainer on nuget.org (#47).
- GitHub Packages gets the Nuke.* shims — preserves the existing
  behaviour from the previous workflow.
- GitHub Releases gets all *.nupkg attached to the tag's release page,
  with auto-generated notes via `gh release create --generate-notes`.
  Idempotent — if the release already exists (workflow_dispatch retry),
  uploads/replaces assets via --clobber.

## Tag protection ruleset (applied separately via API)

A repository ruleset now blocks creation/deletion/update of tags
matching v* for non-admins. Bypass actors: RepositoryRole 5 (admin).
Combined with the env approval gate on nuget-org, this gates
production releases at two layers.

The ruleset is configured via API rather than in this YAML
(ruleset:17017817). It was created in the same change but lives in
repo Settings → Rules, not in the workflow file.

## Build.cs not touched

The existing `IPublish.Publish` target and `ICreateGitHubRelease` from
Build.cs are bypassed by this workflow — CI now calls `dotnet nuget
push` and `gh release create` directly. The targets are still available
for local invocation; consolidating or removing them is a follow-up.

## Docs

docs/agents/release-and-versioning.md "Release pipeline" section
rewritten to describe the new shape (trigger, jobs, channel routing,
tag protection, fallback dispatch).

CHANGELOG entry deferred to the umbrella docs PR #276 per the pattern
set in earlier sub-issues — one consolidated v11-restructure entry
rather than fragmented per-PR entries.

Refs #274, milestone #13.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@ChrisonSimtian ChrisonSimtian mentioned this pull request May 29, 2026
Merged
ChrisonSimtian added a commit that referenced this pull request May 29, 2026
@ChrisonSimtian @claude
ci(release): publish v11 to GitHub Packages, not nuget.org (milestone #…
5e4c657 
…13) (#298)

While v11 churns through the rebrand + plugin-foundation work, nothing
should reach the nuget.org userbase. This routes v11 releases to the GH
Packages feed instead:

- Build.cs: IPublish.NuGetSource -> GitHub Packages feed (defensive — the
  Publish target itself can no longer reach nuget.org), NuGetApiKey fed the
  GITHUB_TOKEN.
- release.yml: NuGetApiKey -> secrets.GITHUB_TOKEN; drop the nuget-org
  Environment binding (no nuget.org secret in play). Flags the lost approval
  gate + how to re-add one for GH Packages.

Also lands tools/unlist-v11.0.1-18.json — the record of the 199 existing
11.0.x (package,version) pairs being unlisted from nuget.org (cleanup of
what auto-published between the #220 major bump and the #268 stopgap).

nuget.org stays reserved for the maintenance 10.x line and a future
stabilised v11. Revisit the feed when v11 stabilises.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

Release-branch model & multi-channel CD

Development

Successfully merging this pull request may close these issues.

1 participant

@ChrisonSimtian