Continuous integration updated for Helm prereleases

nicktrn

·Apr 28, 2026·#3461ci(helm): roll prereleases on main pushes + manual trigger

The continuous integration pipeline can now automatically generate Helm chart prereleases on main branch pushes and via manual triggers, allowing developers to test deployable charts with actual Docker images before full releases.

Previously, Helm prereleases only fired during active pull requests. This caused testing friction, as the generated charts often referenced application image versions that had not been built yet, making end-to-end installation impossible until after the code was merged.

The continuous integration pipeline is being expanded to trigger Helm chart prereleases directly on main branch pushes and through manual workflow dispatches. When triggered from the main branch, the pipeline retains the last stable application version in the chart, so the deployment pulls existing, testable Docker images. Manual triggers also include a new configuration option to override the application version on demand.

These updates to the continuous integration tooling resolve the deployment deadlocks that occurred during release preparations. Developers can now verify that chart structures are fully deployable before cutting an official release for Kubernetes hosting.

View Original GitHub Description

Today the helm prerelease workflow only fires on PRs that touch hosting/k8s/helm/**. Two consequences we ran into:

The changeset-release/main PR's prerelease comment goes stale once the release branch gets force-pushed without a helm-touching commit (the bot's Chart.yaml bump alone doesn't seem to refire the trigger reliably).
The release PR's chart references an appVersion (e.g. v4.4.5) whose Docker images don't exist until after merge + tag. So that prerelease chart can't actually be installed end-to-end.

Renames the workflow to helm-prerelease.yml and adds two new triggers:

push: main with paths: hosting/k8s/helm/** -> rolling prereleases versioned <base>-main.<sha>. appVersion stays at whatever Chart.yaml has (i.e. last released), so installs pull real images. Tests that chart structure is deployable, even if the app code is one release behind.
workflow_dispatch with optional app_version input -> manually trigger a prerelease and optionally override appVersion (e.g. pin to main or a specific tag). Useful for testing chart + app-version combinations on demand.

PR behavior unchanged: same <base>-pr<N>.<sha> versioning, same posted/updated comment.

Why not also bypass paths for changeset-release/main? The release PR's chart references not-yet-built v4.4.5 images, so those prereleases aren't actually installable. The rolling main prerelease covers the testable case better.

Why not SHA-pin appVersion to a built image like main-<sha>? Bigger change - the docker publish workflows currently only push :main (no SHA-suffixed tag). Worth doing later if we want first-class "install one chart, get exactly that commit's app code" testing, but out of scope here.

Diff is mostly a rename. Substantive changes:

new push and workflow_dispatch triggers
prerelease job if: extended for the new event types
version logic branches per event
new "Override appVersion" step (workflow_dispatch only)
new "Write run summary" step so non-PR runs surface the install instructions
PR comment steps gated on github.event_name == 'pull_request'
concurrency group falls back to github.ref for non-PR runs