fix(ci): publish helm charts via forgejo api instead of github plugin #7

Merged

rs merged 1 commit from fix/ci-helm-publish into main

2026-09-02 21:48:23 +00:00

rs commented

2026-09-02 21:30:01 +00:00

Owner

The helm job of release_on_main fails on main since the last release run:

error: unable to get repository
fatal: could not read username for github.com: no such device or address
fatal: expected flush after ref listing
exit status 128

Cause

helm plugin install https://github.com/chartmuseum/helm-push clones the plugin repo with git from inside the job container. The runner's in-container egress to github.com now returns an auth challenge, so git tries to prompt for credentials and dies on the missing TTY (exit 128). The plugin repo itself is public and fine — this is a runtime network dependency on github.com that the release pipeline shouldn't have at all.

Fix

Drop the plugin (and the helm repo add it required) and upload the packaged chart with a single curl to Forgejo's native chartmuseum-compatible endpoint — the same endpoint cm-push posts to under the hood, so publish behavior (incl. re-publishing v0.0.1 from main) is unchanged:

- run: curl --fail --user "rs:${{ secrets.PUSHER_PAT }}" -X POST https://git.pr0.tech/api/packages/rs/helm/api/charts -F "chart=@acidwaifu-v0.0.1.tgz"

Applied to both release_on_main.yaml and release_on_tag.yaml (tag workflow uses acidwaifu-${{ forgejo.ref_name }}.tgz); everything else (helm lint, helm package) is untouched. The endpoint was verified to exist on this instance (401 unauthenticated, not 404).

No more github.com dependency at publish time — only setup-helm (runner-side action fetch, still working) and your own Forgejo.

Verification

Both workflows YAML-validated
Endpoint existence verified against the live instance
Chart packaging reproduced locally on main's chart (helm lint + helm package pass, helm v3.16.4)

The `helm` job of `release_on_main` fails on main since the last release run: ``` error: unable to get repository fatal: could not read username for github.com: no such device or address fatal: expected flush after ref listing exit status 128 ``` ## Cause `helm plugin install https://github.com/chartmuseum/helm-push` clones the plugin repo with `git` from inside the job container. The runner's in-container egress to github.com now returns an auth challenge, so git tries to prompt for credentials and dies on the missing TTY (`exit 128`). The plugin repo itself is public and fine — this is a runtime network dependency on github.com that the release pipeline shouldn't have at all. ## Fix Drop the plugin (and the `helm repo add` it required) and upload the packaged chart with a single `curl` to Forgejo's **native chartmuseum-compatible endpoint** — the same endpoint `cm-push` posts to under the hood, so publish behavior (incl. re-publishing `v0.0.1` from main) is unchanged: ```yaml - run: curl --fail --user "rs:${{ secrets.PUSHER_PAT }}" -X POST https://git.pr0.tech/api/packages/rs/helm/api/charts -F "chart=@acidwaifu-v0.0.1.tgz" ``` Applied to both `release_on_main.yaml` and `release_on_tag.yaml` (tag workflow uses `acidwaifu-${{ forgejo.ref_name }}.tgz`); everything else (`helm lint`, `helm package`) is untouched. The endpoint was verified to exist on this instance (401 unauthenticated, not 404). No more github.com dependency at publish time — only `setup-helm` (runner-side action fetch, still working) and your own Forgejo. ## Verification - Both workflows YAML-validated - Endpoint existence verified against the live instance - Chart packaging reproduced locally on `main`'s chart (`helm lint` + `helm package` pass, helm v3.16.4)

rs added 1 commit

2026-09-02 21:30:02 +00:00