chore(main): release 0.9.5 - #141
Merged
emmanuel merged 2 commits intoAug 8, 2026
Merged
Conversation
github-actions
Bot
force-pushed
the
release-please--branches--main--components--xapi-lrs
branch
from
August 7, 2026 23:26
fd9cd67 to
5d7e29a
Compare
emmanuel
added a commit
that referenced
this pull request
Aug 8, 2026
The app and chart packages were triggering each other in a loop. A chart release commit writes charts/**, plus the manifest release-please updates — and with a single manifest at the repo root, that last file landed outside charts/. The app package's exclude-paths could not filter it: exclusions match directory prefixes only (isRelevant tests file.indexOf(path + '/') === 0), so naming an individual file never matches, which I verified against the source and by dry-run. So the chart's release counted as an app change and produced an app release containing nothing but that chart release (#141, whose sole changelog entry is 'release xapi-lrs-chart 0.1.2'). That app release commit then rewrites Chart.yaml and values.yaml through extra-files, which triggers the next chart release, and so on — each cycle publishing an image and a chart with no real changes in either. Splits the chart onto its own config and manifest, both under charts/, so everything its release commit writes is inside the directory the app package already excludes. The workflow gains a second release-please invocation, and the chart_* outputs now come from it. Only the chart -> app direction is severed. app -> chart is deliberately kept: app releases still rewrite Chart.yaml/values.yaml via extra-files, which is what auto-bumps and republishes the chart. Validated by dry-run against a pushed branch: * a simulated chart release commit touching only charts/** is ABSENT from the app's candidate; * the chart still finds its own last release (xapi-lrs-chart/0.1.2) from the new manifest and correctly skips when nothing changed; * a simulated app release commit still drives the chart from 0.1.2 to 0.1.3. Historical commits are unaffected — 2cc210e already touched the old shared manifest, so the pending 0.9.5 (#141) is still proposed and should be closed rather than merged.
emmanuel
added a commit
that referenced
this pull request
Aug 8, 2026
The app and chart were separate release-please packages, which made them release each other in a loop. A chart release commit writes charts/** plus the shared root manifest; that manifest sits outside charts/, so the app package's exclude-paths could not filter it (exclusions match directory prefixes only, never an individual file). The chart's release therefore counted as an app change and produced an app release containing nothing but that chart release (#141), whose own commit rewrote Chart.yaml and values.yaml via extra-files, triggering the next chart release, and so on. Collapses the two packages into one. Chart.yaml's version now carries a release-please marker alongside appVersion, so a single release drives the chart version, the appVersion and values.yaml's image.tag together. With one package there is no second release to trigger and nothing to loop. This is a deliberate trade. The chart exists only to deploy this application and its appVersion already tracked app releases, so independent semver was buying little; against that, chart-only edits now bump the app version and republish an identical image, and the chart version jumps 0.1.2 -> 0.9.5. exclude-paths is removed accordingly — with it, chart-only changes would release nothing at all. Retagging the previous image with crane instead of rebuilding was considered and rejected: package.json ships in the runtime image and src/tracing.ts reads its version for OpenTelemetry, so every release genuinely changes the image and a retag would report the previous version in traces. Also drops BUILD_VERSION, which was passed to every build and consumed by nothing — the Dockerfile has no ARG for it. In its place the builds now apply docker/metadata-action's labels, which were being computed and thrown away, so images finally carry org.opencontainers.image.version/revision/source. build-dev had no metadata step at all, so it gains one; without it the labels expression would have silently resolved to empty. Validated by dry-run against a pushed branch: one candidate (path '.'), no chart package, 0.9.4 -> 0.9.5, with Chart.yaml and values.yaml as generic updaters — and simulating that release writes version, appVersion and image.tag all as 0.9.5.
emmanuel
added a commit
that referenced
this pull request
Aug 8, 2026
The app and chart were separate release-please packages, which made them release each other in a loop. A chart release commit writes charts/** plus the shared root manifest; that manifest sits outside charts/, so the app package's exclude-paths could not filter it (exclusions match directory prefixes only, never an individual file). The chart's release therefore counted as an app change and produced an app release containing nothing but that chart release (#141), whose own commit rewrote Chart.yaml and values.yaml via extra-files, triggering the next chart release, and so on. Collapses the two packages into one. Chart.yaml's version now carries a release-please marker alongside appVersion, so a single release drives the chart version, the appVersion and values.yaml's image.tag together. With one package there is no second release to trigger and nothing to loop. This is a deliberate trade. The chart exists only to deploy this application and its appVersion already tracked app releases, so independent semver was buying little; against that, chart-only edits now bump the app version and republish an identical image, and the chart version jumps 0.1.2 -> 0.9.5. exclude-paths is removed accordingly — with it, chart-only changes would release nothing at all. Retagging the previous image with crane instead of rebuilding was considered and rejected: package.json ships in the runtime image and src/tracing.ts reads its version for OpenTelemetry, so every release genuinely changes the image and a retag would report the previous version in traces. Also drops BUILD_VERSION, which was passed to every build and consumed by nothing — the Dockerfile has no ARG for it. In its place the builds now apply docker/metadata-action's labels, which were being computed and thrown away, so images finally carry org.opencontainers.image.version/revision/source. build-dev had no metadata step at all, so it gains one; without it the labels expression would have silently resolved to empty. Validated by dry-run against a pushed branch: one candidate (path '.'), no chart package, 0.9.4 -> 0.9.5, with Chart.yaml and values.yaml as generic updaters — and simulating that release writes version, appVersion and image.tag all as 0.9.5.
github-actions
Bot
force-pushed
the
release-please--branches--main--components--xapi-lrs
branch
from
August 8, 2026 01:51
3cd9ae8 to
a8809f4
Compare
emmanuel
approved these changes
Aug 8, 2026
emmanuel
deleted the
release-please--branches--main--components--xapi-lrs
branch
August 8, 2026 02:07
Contributor
Author
|
🤖 Created releases: 🌻 |
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
1 participant
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.
🤖 I have created a release beep boop
0.9.5 (2026-08-08)
Bug Fixes
Chores
This PR was generated with Release Please. See documentation.