Revert the GitHub workflow guard to server_url

Misdiagnosed the earlier report: Gitea was correctly running its own .gitea/workflows copy, not this .github one, so the server_url guard was fine. The switch to a GITHUB_RELEASE repo variable then made the workflow skip on GitHub itself, since that variable is not set there. Put both job guards back to `github.server_url == 'https://github.com'`, which runs on GitHub with no manual setup and skips on Gitea (its .gitea copy is the one that runs). No repository variable is needed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gate the GitHub release workflow on a repo variable, not server_url
2026-10-02 12:53:26 +01:00 · 2026-10-02 12:50:04 +01:00
1 changed files with 4 additions and 4 deletions
@@ -5,10 +5,10 @@ name: Release
 # macOS and Windows); only the publish half differs: GitHub needs the v4
 # artifact backend and fills the release with `gh`.
 #
-# Gitea reads both .gitea/workflows and .github/workflows, so without a guard it
+# Every job is gated on `github.server_url == 'https://github.com'`, so this file
-# would also try to run this file and fail on @v4 and `gh`. Every job is gated
+# runs only on GitHub. Gitea runs its own copy in .gitea/workflows; should a
-# on running on github.com, so on Gitea they are simply skipped — the Gitea file
+# Gitea instance also read .github/workflows, the guard skips these jobs there
-# is the one that runs there.
+# so they never fail on the @v4 artifact backend or `gh`.
 on:
  push:
    tags: ["v*"]