The AUR publish workflow's failure the user reported was not an AUR-credentials problem — it never even reached the Push to AUR step. Root cause: the Render PKGBUILD step's Python heredoc built a match string via an f-string escaping literal braces as ${{pkgver}}, which put that exact 4-character sequence directly in the workflow's own YAML run: text. Gitea Actions scans run: blocks for ${{ ... }} and tries to evaluate the contents as one of its own expressions before the shell ever runs the script; pkgver is not a valid expression context, so the interpolation silently failed and emptied the whole step. The next step then failed with a confusing PKGBUILD does not exist.
Fixed by building the same string with a $ variable and plain concatenation, so the file's own text never contains the trigger sequence. Verified by extracting the exact heredoc and running it standalone (bash + python3) against the real packaging/arch/PKGBUILD template — renders byte-for-byte the intended output.
Test plan
Extracted the heredoc via a YAML parse and confirmed it still parses as valid Python
Ran the exact bash+python heredoc standalone against the real PKGBUILD template with fake version/checksums — rendered correctly, no leftover SKIP placeholders
Re-run Publish AUR Package via workflow_dispatch after merge to confirm the real CI job gets past the render/validate steps
The AUR publish workflow's failure the user reported was not an AUR-credentials problem — it never even reached the `Push to AUR` step. Root cause: the `Render PKGBUILD` step's Python heredoc built a match string via an f-string escaping literal braces as `${{pkgver}}`, which put that exact 4-character sequence directly in the workflow's own YAML `run:` text. Gitea Actions scans `run:` blocks for `${{ ... }}` and tries to evaluate the contents as one of its own expressions before the shell ever runs the script; `pkgver` is not a valid expression context, so the interpolation silently failed and emptied the whole step. The next step then failed with a confusing `PKGBUILD does not exist`.
Fixed by building the same string with a `$` variable and plain concatenation, so the file's own text never contains the trigger sequence. Verified by extracting the exact heredoc and running it standalone (bash + python3) against the real `packaging/arch/PKGBUILD` template — renders byte-for-byte the intended output.
## Test plan
- [x] Extracted the heredoc via a YAML parse and confirmed it still parses as valid Python
- [x] Ran the exact bash+python heredoc standalone against the real PKGBUILD template with fake version/checksums — rendered correctly, no leftover SKIP placeholders
- [ ] Re-run `Publish AUR Package` via workflow_dispatch after merge to confirm the real CI job gets past the render/validate steps
The "Render PKGBUILD" step's Python heredoc built its old_source match
string via an f-string, escaping literal braces as `${{pkgver}}` — which
put that exact four-character sequence directly in this workflow file's
own YAML text. Gitea Actions scans a run: block for `${{ ... }}` and tries
to evaluate whatever's inside as one of its own expressions before the
shell ever sees the script; "pkgver" isn't a valid expression context, so
every run has been failing that interpolation and emptying the step
instead of raising anything visible there. The next step's `makepkg` then
failed with "PKGBUILD does not exist" — the actual point of failure was
one step earlier and unrelated to AUR credentials.
Rebuilt the same match string with a "$" variable and plain concatenation
so the file's own text never contains the trigger sequence. Verified by
extracting the exact heredoc and running it standalone against the real
PKGBUILD template — renders identically to the intended output.
jknapp
merged commit 7489516df3 into main2026-08-27 21:40:05 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The AUR publish workflow's failure the user reported was not an AUR-credentials problem — it never even reached the
Push to AURstep. Root cause: theRender PKGBUILDstep's Python heredoc built a match string via an f-string escaping literal braces as${{pkgver}}, which put that exact 4-character sequence directly in the workflow's own YAMLrun:text. Gitea Actions scansrun:blocks for${{ ... }}and tries to evaluate the contents as one of its own expressions before the shell ever runs the script;pkgveris not a valid expression context, so the interpolation silently failed and emptied the whole step. The next step then failed with a confusingPKGBUILD does not exist.Fixed by building the same string with a
$variable and plain concatenation, so the file's own text never contains the trigger sequence. Verified by extracting the exact heredoc and running it standalone (bash + python3) against the realpackaging/arch/PKGBUILDtemplate — renders byte-for-byte the intended output.Test plan
Publish AUR Packagevia workflow_dispatch after merge to confirm the real CI job gets past the render/validate stepsThe "Render PKGBUILD" step's Python heredoc built its old_source match string via an f-string, escaping literal braces as `${{pkgver}}` — which put that exact four-character sequence directly in this workflow file's own YAML text. Gitea Actions scans a run: block for `${{ ... }}` and tries to evaluate whatever's inside as one of its own expressions before the shell ever sees the script; "pkgver" isn't a valid expression context, so every run has been failing that interpolation and emptying the step instead of raising anything visible there. The next step's `makepkg` then failed with "PKGBUILD does not exist" — the actual point of failure was one step earlier and unrelated to AUR credentials. Rebuilt the same match string with a "$" variable and plain concatenation so the file's own text never contains the trigger sequence. Verified by extracting the exact heredoc and running it standalone against the real PKGBUILD template — renders identically to the intended output.