fix(ci): publish lets-chat-desktop releases to the private package org #107
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/publish-release-private-package-org"
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
The
publish-release.ymlworkflow shipped in #103 was uploading via--user "${GITHUB_REPOSITORY_OWNER}:${secrets.FORGEJO_PAT}", so on a tag push the curl calls either landed under the wrong owner namespace or failed silently becausesecrets.FORGEJO_PATis not provisioned on this repo. None of the binaries showed up in the Generic Packages tab. Every other repo under~/projects/a8n-run/(da-os, file-explorer, backup, eform, saas, storefront, rusty-links, icanhazrust, ...) publishes via the shared org variables instead. This PR aligns lets-chat with that pattern.Changes
.forgejo/workflows/publish-release.yml:a8n-tools->${{ vars.A8N_TOOLS_PRIVATE_PACKAGE_OWNER }}.FORGEJO_PAT->FORGEJO_TOKENpopulated from${{ secrets.A8N_TOOLS_PRIVATE_PACKAGE_PAT }}, which is the secret name the other workflows in the org consume.--user "$user:$token"->--header "Authorization: token $token". Bearer-style auth is what the rest of the org's generic-package uploads use; the now-unusedGITHUB_REPOSITORY_OWNERlookup is dropped.The destination URL still resolves to
${GITHUB_SERVER_URL}/api/packages/${vars.A8N_TOOLS_PRIVATE_PACKAGE_OWNER}/generic/lets-chat/{version,latest}/.... If the org variable is set toa8n-tools(which is what the desktop self-updater's compiled-inDEFAULT_UPDATE_URLalready targets), no client-side change is needed; if the variable points at a different org, the desktop client just needsLETS_CHAT_UPDATE_URLoverridden to match.Test plan
da-os/.forgejo/workflows/build-{linux,windows}.yml,backup/.forgejo/workflows/build-oci-image.yml, etc.v*tag push uploads the Linux + Windows binaries andlatest.jsonunder the${vars.A8N_TOOLS_PRIVATE_PACKAGE_OWNER}/generic/lets-chat/...namespace and they appear in the Forgejo Generic Packages UI.curl -L "${GITHUB_SERVER_URL}/api/packages/${ORG}/generic/lets-chat/latest/latest.json"returns the manifest JSON after the workflow run completes.Match the pattern every other repo under ~/projects/a8n-run/ uses (da-os, file-explorer, backup, eform, saas, storefront, rusty-links, icanhazrust, ...) so the binaries land in the private a8n-tools org's Generic Packages namespace instead of the per-repo `GITHUB_REPOSITORY_OWNER` namespace nothing else looks at. Three changes inside `.forgejo/workflows/publish-release.yml`: - Owner: hardcoded literal `a8n-tools` -> `${{ vars.A8N_TOOLS_PRIVATE_PACKAGE_OWNER }}` so the destination follows the org variable instead of a magic string in this file. - Auth: secret rename `FORGEJO_PAT` -> `FORGEJO_TOKEN` populated from `${{ secrets.A8N_TOOLS_PRIVATE_PACKAGE_PAT }}` (the same secret name the other workflows in the org consume). The previous `FORGEJO_PAT` secret was not provisioned on this repo, which is why the curl uploads in the original workflow ended up surfacing as workflow-run output instead of as Generic Packages entries. - Curl auth method: `--user "$user:$token"` -> `--header "Authorization: token $token"`. Bearer-style auth is what the rest of the org's `^curl ... --upload-file ... ($url)` invocations use; it also drops the now-unused `GITHUB_REPOSITORY_OWNER` lookup. The destination URL still resolves to `${GITHUB_SERVER_URL}/api/packages/${vars.A8N_TOOLS_PRIVATE_PACKAGE_OWNER}/generic/lets-chat/{version,latest}/...`. Provided the org variable is set to `a8n-tools` (which is what the desktop self-updater's compiled-in `DEFAULT_UPDATE_URL` already assumes), no client-side change is needed; if the org variable is set to a different name the desktop client just needs `LETS_CHAT_UPDATE_URL` pointed at it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>