The publishing step needs the secret after all

A manual build printed a forge credential, so the last change dropped the secret and
relied on it. The first tag build then built all four packages and died at the publishing
step with no credential at all: a build started by the tag webhook does not get one.

So `gitea_token` is a repository secret again, mapped into the step, with the forge
credential kept as a fallback for the manual case. The README and the wiki now describe
what was measured rather than what the manual build suggested.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.woodpecker.yaml

@@ -58,9 +58,13 @@ steps:
   # from the Mac that can sign them.
   - name: release
     image: alpine
-    # No secret: the step authenticates with the forge credential Woodpecker already
+    environment:
-    # hands every step, which belongs to the repository's owner. To publish as someone
+      # Needed. Woodpecker does hand steps a forge credential — a manual build printed
-    # else instead, add a `gitea_token` repository secret and map it here as GITEA_TOKEN.
+      # one — but a build started by the tag webhook does not get it: the first tag build
+      # died here with no credential at all. So the token is a repository secret, and the
+      # script still falls back to the forge credential when it is there.
+      GITEA_TOKEN:
+        from_secret: gitea_token
     commands:
       - apk add --no-cache curl jq
       # No globs on the command line: the package names have spaces in them.

README.md

@@ -204,11 +204,20 @@ So the whole of a release is:
 
 The window test is local as well: it needs a display and a store on the machine.
 
-The `release` step needs **no secret**. It authenticates with the forge credential
+The `release` step needs a **`gitea_token`** repository secret — a Gitea token with
-Woodpecker hands every step for cloning, which is an access token of the repository's
+write access to this repository:
-owner; Gitea takes it as `token …` or `Bearer …` depending on how Woodpecker was set up,
+
-so `scripts/ci-upload.sh` probes which of the two works instead of assuming. To publish
+```sh
-as somebody else, add a `gitea_token` repository secret and map it into the step.
+woodpecker-cli repo secret add --repository stores/warp-engine-client \
+  --name gitea_token --value <token> --event tag
+```
+
+Woodpecker does hand steps a forge credential of its own, and the script uses it when the
+secret is absent, but that is not something to rely on: a **manual** build has it and a
+build started by the **tag webhook** does not, which is how the first tag build failed —
+after building all four packages. Gitea takes either credential as `token …` or
+`Bearer …` depending on how it was issued, so the script probes which of the two `/user`
+accepts instead of assuming, and logs which one it used.
 
 There are two publishers on purpose: `scripts/release.sh` drives `tea`, which is logged
 in on a workstation, and `scripts/ci-upload.sh` speaks the API with whatever credential

RELEASE_NOTES.md

@@ -62,8 +62,7 @@ A `vX.Y.Z` tag now starts the pipeline, which builds the AppImage, the deb, the
 installer and the portable exe — Windows through Wine — **creates this release** and
 attaches all four. macOS stays a local build, because Apple's toolchain and its signing
 exist only on a Mac, so `make release` from a Mac pushes that package onto the same
-release afterwards. No secret is involved: the pipeline publishes with the forge
+release afterwards. Publishing uses a `gitea_token` repository secret in Woodpecker.
-credential Woodpecker already gives every step.
 
 The Windows installer is not signed: Windows will warn about an unknown publisher until
 there is a certificate.