fix: apply HelmReleaseName truncation in releaseKey for GC comparison#5302
Merged
0xavi0 merged 1 commit intoJul 3, 2026
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This pull request fixes a Helm release-name mismatch in the agent garbage collector by ensuring the GC computes the expected release key using the same truncation/sanitization logic as the Helm deployer when helm.releaseName is not explicitly set. This prevents valid releases (especially for BundleDeployment names > 53 characters) from being incorrectly treated as “unknown” and uninstalled.
Changes:
- Apply
names.HelmReleaseName(bd.Name)inreleaseKey()when no explicitHelm.ReleaseNameis configured. - Add a regression test covering the “no explicit releaseName + long bundle ID” case to ensure the GC does not delete the valid release.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| internal/cmd/agent/deployer/cleanup/cleanup.go | Aligns GC’s expected release key derivation with deployer behavior by applying HelmReleaseName when releaseName is implicit. |
| internal/cmd/agent/deployer/cleanup/cleanup_test.go | Adds a focused test to prevent regressions for long BundleDeployment names without an explicit Helm release name. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
When no explicit Helm.ReleaseName is configured, the deployer derives the helm release name via names.HelmReleaseName(bundleID), which truncates names longer than 53 characters and appends a 5-char hash. The releaseKey function in cleanup.go was using bd.Name directly, causing a mismatch against the actual truncated release name stored in helm secrets. This caused the garbage collector to incorrectly flag valid releases as unknown and delete them, logging: "Deleting unknown bundle ID, helm uninstall" ... "release":"default/...-742e3","expectedRelease":"default/...-5nj4is" Fix: apply names.HelmReleaseName() in releaseKey when no explicit release name is set, mirroring what deployer.getOpts() does.
33010df to
5ee363e
Compare
This was referenced Jul 6, 2026
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.
Refers to #5261
When no explicit Helm.ReleaseName is configured, the deployer derives the helm release name via names.HelmReleaseName(bundleID), which truncates names longer than 53 characters and appends a 5-char hash. The releaseKey function in cleanup.go was using bd.Name directly, causing a mismatch against the actual truncated release name stored in helm secrets.
This caused the garbage collector to incorrectly flag valid releases as unknown and delete them, logging:
"Deleting unknown bundle ID, helm uninstall" ...
"release":"default/...-742e3","expectedRelease":"default/...-5nj4is"
Fix: apply names.HelmReleaseName() in releaseKey when no explicit release name is set, mirroring what deployer.getOpts() does.