fix(static-site): resolve vendored common subchart dependency (unblocks Release) - #235
Merged
Merged
Conversation
darkobas2
force-pushed
the
fix/static-site-vendored-common-dependency
branch
3 times, most recently
from
August 12, 2026 08:04
8d4ac46 to
78de235
Compare
The Release workflow has failed on every push to master since 2026-08-02
with:
Error: directory /home/runner/work/helm/helm/charts/common not found
chart-releaser runs `helm dependency update`, which tries to resolve
static-site's dependency on the common library chart. Chart.yaml carried
upstream's `repository: file://../common`, which points at a sibling
`charts/common` directory in the onechart monorepo. No such directory
exists here, so resolution fails and the whole release job aborts - not
just for static-site, but for every chart in the repo.
The subchart was vendored as a packaged `charts/common-0.7.0.tgz`. That is
enough for `helm template` and `helm install`, which is why deployments
were unaffected and the breakage went unnoticed, but it does not satisfy
dependency resolution.
Fixed by matching the convention beeport-ui already uses in this repo:
declare `repository: file://charts/common` and vendor the subchart as an
unpacked directory rather than a tarball.
Verified against a clean clone:
- helm dependency update - previously failed, now succeeds, and is
idempotent across repeated runs
- helm lint - passes
- helm package - passes
- helm template - byte-for-byte identical output to before
No template or values changes. Chart version is bumped 0.73.0 -> 0.73.1
because chart-testing requires a bump for any modified chart; the only
resulting difference in rendered output is the helm.sh/chart label.
PROVENANCE.md records that templates remain upstream v0.73.0 verbatim.
Also adds charts/static-site/ci/ct-values.yaml. The chart's default values
clone an archived org's demo app and run a full `npm install && npm run
build`, so `ct install` crash-loops the init container and can never pass.
The CI values clone this repository and emit a trivial asset, exercising the
same clone -> build -> copy path. This was never caught because the original
vendoring was pushed straight to master without a PR, so chart-testing had
never run against this chart.
Introduced in d631deb ("feat(static-site): vendor onechart static-site
chart v0.73.0").
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
darkobas2
force-pushed
the
fix/static-site-vendored-common-dependency
branch
from
August 12, 2026 08:13
78de235 to
fc886fd
Compare
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.
Problem
The Release workflow has failed on every push to
mastersince 2026-08-02:chart-releaserrunshelm dependency update, which tries to resolvestatic-site's dependency on thecommonlibrary chart.Chart.yamlcarriedupstream's
repository: file://../common— a path that points at a siblingcharts/commondirectory in the onechart monorepo. No such directory exists inthis repo, so resolution fails and the release job aborts for every chart,
not just
static-site.The subchart was vendored, but as a packaged
charts/common-0.7.0.tgz. Thatsatisfies
helm templateandhelm install— which is why deployments keptworking and this went unnoticed for ten days — but not dependency resolution.
Today's merge of #234 didn't cause this; it was simply the first push to
mastersince the breakage, so it surfaced it.Fix
Match the convention
beeport-uialready uses in this repo:repository: file://../common→repository: file://charts/commoncharts/common/directory instead of a tarballVerification
Against a clean clone:
helm dependency updatehelm linthelm packagehelm templateNo template or values changes. Chart version is bumped
0.73.0->0.73.1because
chart-testingenforces a version bump on any modified chart; the onlyresulting difference in rendered output is the
helm.sh/chartlabel.PROVENANCE.mdrecords that templates remain upstreamv0.73.0verbatim.Also included
chart-testinghad never run against this chart — the original vendoringwas pushed straight to
masterwithout a PR — so it surfaced three furthergates the moment the chart counted as changed:
ctfor any modified chart (0.73.0->0.73.1)values.yamlother chart here carries
ci/ct-values.yaml: the defaults clone an archived org's demo app and runa full
npm install && npm run build, soct installcrash-looped the initcontainer. The CI values clone this repository and emit a trivial asset,
exercising the same clone -> build -> copy path.
buildImagestays at thechart's default
node:latest, so no new image dependency.Origin
Introduced in d631deb ("feat(static-site): vendor onechart static-site chart
v0.73.0") — the packaged subchart was copied across but upstream's
file://path was left pointing at a layout that doesn't exist here.