Repository navigation
Fix the exporter release upload: token as input, not env var - #54
Merged
Merged
Conversation
The v1.0.5 release published with no assets. Both binaries built and uploaded as
workflow artifacts; only the final step failed:
Unexpected error fetching GitHub release for tag refs/tags/macos-exporter-v1.0.5:
HttpError: Resource not accessible by integration
softprops/action-gh-release@v2 takes its credential as the `token` input, which
defaults to ${{ github.token }}. Its own documentation says "a non-empty
explicit token overrides GITHUB_TOKEN" - and since the default is always
non-empty, the GITHUB_TOKEN environment variable this workflow set was ignored
outright. The PAT was never used. It authenticated as the built-in token, whose
contents permission is read-only for this repository, and so could not update
the release.
Passing the env var is the v1 idiom, which is presumably where it came from.
Also granting contents: write to both build jobs, so an unset or expired PAT
degrades to a working upload rather than a 403 - the action treats an empty
token as unset and falls back to the built-in one.
Nothing to do with the version wiring changed for 1.0.5: every step that used it
succeeded, including naming and uploading both zips.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
saamdotexe
pushed a commit
to saamdotexe/OpenTagViewer
that referenced
this pull request
Oct 22, 2026
…t-token Fix the exporter release upload: token as input, not env var
saamdotexe
pushed a commit
to saamdotexe/OpenTagViewer
that referenced
this pull request
Oct 22, 2026
build-release.yml had the identical wiring the exporter workflow did: the PAT
passed to softprops/action-gh-release@v2 as a GITHUB_TOKEN environment
variable. The action's `token` input defaults to ${{ github.token }}, and its
docs say "a non-empty explicit token overrides GITHUB_TOKEN" - so the default is
always non-empty and the env var is ignored. It authenticates as the built-in
token, which is read-only here, and fails with 403 after the APK has been built
and signed.
parawanderer#54 fixed this for the exporter because that was the release being cut. This
workflow was never re-run, so it has been sitting on the same fault - and the
next Android release would have failed at the last step, after the signing, in
exactly the same way.
Token moved into `with:`, and contents: write granted to the job so an unset or
expired PAT degrades to a working upload rather than a 403.
Checked the other workflows: update-contributors.yml also sets GITHUB_TOKEN as
an environment variable, but that one is the built-in token being handed to
scripts/fetch_contributors.py, which reads it from the environment. Not the same
thing, and correct as written.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The v1.0.5 release published with no assets attached. Both binaries built fine — only the last step failed:
Cause
softprops/action-gh-release@v2takes its credential as thetokeninput, which defaults to${{ github.token }}. From the action's ownaction.yml:Since the default is always non-empty, the
GITHUB_TOKEN:env var this workflow set was ignored outright — the PAT inMACOS_EXPORTER_APP_GITHUB_TOKENwas never used. The action authenticated as the built-in token, and this repository's default workflow permission is read-only:{"default_workflow_permissions": "read", "can_approve_pull_request_reviews": false}so it could not update the release. The action's documentation names this exact symptom.
Setting the token via
env:is the v1 idiom, which is presumably where it came from.Fix
tokeninput on both build jobspermissions: contents: writeto those jobs as well, so an unset or expired PAT degrades to a working upload rather than a 403 — the action treats an empty token as unset and falls back to the built-in oneNot related to the version wiring
Every step touching the
APP_VERSIONoutput added in #49 succeeded:test-release-versionpassed the tag/source check, and both zips were named and uploaded correctly. The failure was purely authentication on the final upload.Unblocking v1.0.5 in the meantime
The built zips are attached to the failed run as workflow artifacts, so they can be downloaded and added to the release by hand without waiting for this. Re-running the failed jobs will not help on its own — a re-run replays the workflow file from that run, so it needs this merged and the release event re-fired.
🤖 Generated with Claude Code