Skip to content

Make manual release runs resolve their tag from VERSION or an input - #51

Draft
AminMGMT wants to merge 1 commit into
mainfrom
claude/project-thread-k09kit
Draft

AminMGMT wants to merge 1 commit into
mainfrom
claude/project-thread-k09kit

Conversation

@AminMGMT

Copy link
Copy Markdown
Owner

Requested by Amin · project thread

Before: starting the Release workflow by hand on main failed with "Tag main does not match VERSION", because the tag was read from GITHUB_REF_NAME, which is the branch name on a manual run.

After: a manual run publishes the commit it was started on under the tag input, or under VERSION when the input is blank. Tag-push releases behave exactly as before, and the tag must still match VERSION.

How: a new "Resolve the tag" step runs first. It uses the pushed tag, or the input, or VERSION, and validates the format (vX.Y.Z or vX.Y.Z-suffix). On a manual run it also refuses a tag that already exists at a different commit, so main's binaries can't be published under an older tag. The later steps read that resolved tag, and the publish step gets tag_name and target_commitish explicitly. The SHA256SUMS signing step (RELEASE_SIGNING_KEY, tools/signsums) is unchanged.

Testing: the resolve script was run locally for these cases: blank input on main, a beta input, a run started on a tag, a tag/input mismatch, a malformed input, and an existing tag on another commit.

🤖 Generated with Claude Code

https://claude.ai/code/session_0134fKrsTGERpK7wYrFGoSNz


Generated by Claude Code

A workflow_dispatch run on main had GITHUB_REF_NAME=main, so the tag check
failed with 'Tag main does not match VERSION'. Manual runs now take the tag
from a 'tag' input or from VERSION, refuse a tag that already exists at a
different commit, and pass tag_name to the publish step. Tag pushes behave
as before, and the tag must still match VERSION.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0134fKrsTGERpK7wYrFGoSNz
@AminMGMT AminMGMT self-assigned this Sep 27, 2026

Copy link
Copy Markdown
Owner Author

Build and test failed in the race-detector pass on TestLocalBackendDialNeverUsesTheProxy (internal/e2e/proxy_test.go). This PR only touches .github/workflows/release.yml, and that workflow doesn't run on pull requests, so the failure isn't caused by this change. The same job passed on main at e60d229.

The race is in the test itself. At line 202 the test calls close(asked) while a fake SOCKS handler goroutine can still be sending to asked at line 183. A late send on the closed channel is flagged as a race, and it could also panic. No fix exists on main yet. The patch below drains the channel instead of closing it. With it applied, go test -race ./internal/e2e/ -run TestLocalBackendDialNeverUsesTheProxy -count=3 passes locally.

-	close(asked)
+	// Drain rather than close: a proxy handler may still be mid-request, and
+	// its send on a closed channel would panic (and is a race besides).
+	var targets []string
+drain:
+	for {
+		select {
+		case target := <-asked:
+			targets = append(targets, target)
+		default:
+			break drain
+		}
+	}
 	seen := 0
-	for target := range asked {
+	for _, target := range targets {

I'm re-running the failed job once.


Generated by Claude Code

Copy link
Copy Markdown
Owner Author

The re-run of Build and test failed again, and this time on a different test: TestAPeerKilledMidTransferDoesNotWedgeTheOther/tcp (internal/e2e/chaos_test.go:93). The message was "cycle 3: the tunnel never came up: dial entry port: connection refused". The proxy test that failed the first run passed this time.

This isn't caused by this PR either, which only changes release.yml. The e2e suite fails intermittently on main too. Run 36166938389 on 2c16915 failed in TestTunnelStatsCountTraffic, and the run before it on 2efab69 also failed.

This one could be a real server-side problem. After two clients were killed mid-transfer, the server's entry port was still refusing connections 20s later, so it may not be a test bug. No fix exists yet, and the one allowed re-run is used up, so I'm not re-running it again. I'm leaving it for a separate investigation rather than widening this PR, and I'll keep watching the PR.


Generated by Claude Code

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