stores/warp-engine-client
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 14 Wiki Activity

The publishing step needs the secret after all
ci/woodpecker/push/woodpecker Pipeline was successful
Details
ci/woodpecker/tag/woodpecker Pipeline was successful
Details

Browse Source 
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>
This commit is contained in:
mr.zero
2026-08-18 17:24:42 +02:00
co-authored by Claude Opus 5
parent 7026e0cc6a
commit a364a5ce5f
3 changed files with 22 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+14 -5
View File
@@ -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
Woodpecker hands every step for cloning, which is an access token of the repository's
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
as somebody else, add a `gitea_token` repository secret and map it into the step.
The `release` step needs a **`gitea_token`** repository secret — a Gitea token with
write access to this repository:
```sh
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