fix(ci): publish desktop binaries to the private package registry #110
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/desktop-workflows-publish-to-packages"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Same gap PR #107 (publish-release.yml) and #109 (build-oci-image.yml) closed, this time on the desktop workflows.
build-desktop-linux.ymlandbuild-desktop-windows.ymlwere uploading the built binary viaforgejo/upload-artifact@v4, which attaches it to the workflow run UI for 90 days but never publishes it anywhere a consumer can fetch from. The last runs landed atactions/runs/3281/artifacts/72andactions/runs/3282/artifacts/71instead of in the Generic Packages namespace, which is what the desktop self-updater (#103) reads when checking for updates.Both workflows now match the org pattern (see da-os/.forgejo/workflows/build-{linux,windows}.yml).
Changes (mirrored across both desktop workflows)
permissions: packages: writeadded.FORGEJO_TOKEN = secrets.A8N_TOOLS_PRIVATE_PACKAGE_PAT,PACKAGE_OWNER = vars.A8N_TOOLS_PRIVATE_PACKAGE_OWNER,PACKAGE_NAME = lets-chat.Upload artifactstep (forgejo/upload-artifact@v4) replaced withUpload binary to Generic Packagesthat DELETE-then-PUTs against${GITHUB_SERVER_URL}/api/packages/${owner}/generic/lets-chat/${version}/lets-chat-desktop-{linux|windows}-x86_64[.exe]withAuthorization: token ${FORGEJO_TOKEN}.Upload URL uses the stable filename
lets-chat-desktop-{linux|windows}-x86_64[.exe](version is already in the URL path), matching what the self-updater's manifest inpublish-release.ymlreferences. The local extract step still names the file with the version for readability when poking around on the runner; only the upload-time filename is stable.Audit
Re-grepped every workflow under
.forgejo/workflows/forupload-artifactand the old auth pattern: zero remaining references toforgejo/upload-artifact@v4, zero remainingsecrets.FORGEJO_PAT, zero remainingGITHUB_REPOSITORY_OWNERdriving a registry push.publish-release.yml's build+upload steps duplicate work with these two workflows onv*tag pushes (it rebuilds both binaries and uploads them to the same URL). The DELETE-then-PUT pattern makes the duplication harmless but is wasted CI time and should be deduplicated in a follow-up - the manifest generation in publish-release.yml is what is uniquely needed.Test plan
mainproduces${ORG}/generic/lets-chat/latest/lets-chat-desktop-linux-x86_64and...windows-x86_64.exein the Generic Packages UI, andactions/runs/.../artifacts/...no longer contains the desktop binary.v*tag push produces${ORG}/generic/lets-chat/v.../lets-chat-desktop-{linux,windows}-x86_64[.exe]plus the existinglatest/latest.jsonmanifest, and the desktop self-updater's--check-updateagainst the deployed URL sees the new version.