fix(blueprint): rc tag support - #2909
Merged
Merged
Conversation
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
Opens the production promotion path from staging to main. Merging this PR triggers semantic-release, then the existing production deployment workflow. Do not squash this PR. Use a merge commit to preserve the original conventional commits for semantic-release.
What:
Stop the service overview from being replaced by the generic error page when
the blueprint update check fails, and surface an orange "RC test" badge in the
services table "Target version" cell for services running a prerelease
blueprint version.
Why:
The service-catalog CI tags every pull request that touches a blueprint with a
throwaway prerelease `{PROVIDER}/{service}/{major}/{version}-pr{PR}.{sha}-rc`,
which is deliberately absent from catalog.json. `GET /blueprint/{id}/update` is
the only endpoint that reports a blueprint service's tag, and q-core answers
404 (`Catalog entry not found`) or 502 (`manifest not found`) for those tags.
react-query v4 makes a suspense query throw on error, and the overview header
had no boundary between it and the organization layout, so a single unresolved
tag blanked the whole page. The same failure left the table cell with no
version and no badge, giving no hint that the service runs a test build.
Notes:
- The badge keys off the tag only, never off the failure. A 404 also covers a
released tag whose major has been retired from the catalog (HELM/redis/7),
and flagging those as prereleases was wrong.
- When the update check cannot answer, a terraform blueprint's tag is still
readable: the engine pins the generated service to it as its git branch
(lib/blueprint/terraform/main.j2.tf). A helm blueprint's generated service
has no git source and no other field carrying the tag, so a prerelease on a
blueprint the catalog does not know at all goes unflagged there — it renders
as it does today rather than guessing.
- The update badge is suppressed for prereleases: the pin is a throwaway, and
"updating" it to the released tag is misleading. For the same reason a helm
prerelease loses its "deploy another version" action — the tag is deleted
when the pull request closes.
- `retry: false` on the update query: a catalog resolution failure is
deterministic, and the retries delayed the overview's suspense fallback.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
View your CI Pipeline Execution ↗ for commit ed11a81
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗ ☁️ Nx Cloud last updated this comment at |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## staging #2909 +/- ##
===========================================
- Coverage 48.46% 46.80% -1.66%
===========================================
Files 1272 509 -763
Lines 27590 13771 -13819
Branches 8114 4195 -3919
===========================================
- Hits 13372 6446 -6926
+ Misses 11952 6202 -5750
+ Partials 2266 1123 -1143
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
All reported issues were addressed across 8 files
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
What:
Match the full prerelease marker instead of the `-rc` ending, keep bounded
retries for non-404 update-check failures, make the RC badge reachable by
keyboard, and drop the "deploy another version" action on a helm blueprint
whose update check cannot answer.
Why:
Four issues raised in review, all confirmed:
- catalog-gen releases whatever version a manifest declares — its own comment
spells out that `1.2.3-rc` is a legal release — so `endsWith('-rc')` would
have replaced a published blueprint's update badge with the RC one. The CI
marker is `-pr{PR}.{short_sha}-rc` (validate.yml), which is what now matches.
- `retry: false` applied to every failure, so a transient error dropped update
data from the service list and pushed the suspense update flow straight to
its error state. Only the deterministic 404 skips retries now.
- The badge is a span, so Radix had no focusable trigger and the explanation
was mouse-only.
- A helm blueprint on a prerelease tag is undetectable when the update check
404s (its generated service carries no tag anywhere), and it was still being
offered "deploy another version" on a pin whose tag disappears with its pull
request. The chart version now renders read-only in that state.
Notes:
- The read-only fallback is deliberately not limited to prereleases: from the
console there is no way to tell one from a retired major, and withholding a
version-changing action under that uncertainty beats guessing a label — the
mistake the previous revision made.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
What:
Render a helm blueprint service's chart version immediately again, and cut the
update check's retry to a single 500ms attempt instead of two exponential ones.
Why:
The "Target version" cell got noticeably slower for helm blueprint services.
Their chart version comes off the service payload and used to paint with the
list, but the prerelease check put a skeleton in front of it: every row waited
on `GET /blueprint/{id}/update`, which fetches catalog.json and two manifests
from GitHub before it answers. The check can only ever downgrade what the
console already knows, so it no longer gates the render — it swaps the badge in
once it answers, and the loading state disappears.
The retry made the other half of it: for a tag whose manifest is gone the API
answers 502, not 404, so the failure path took two retries at the default 1s/2s
backoff — about three seconds of skeleton before settling.
Notes:
- Helm blueprint rows still issue one update check each, which is new: it is the
only way to recognise a prerelease there, since their generated service
carries no tag. It is off the render path now, but on a list with many such
services it is still N extra calls to a slow endpoint.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
All reported issues were addressed across 3 files (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Fix all with cubic | Re-trigger cubic
…k runs What: Treat the in-flight update check like a failed one in the helm blueprint version slot: the chart version still renders immediately, but its "deploy another version" action only appears once the check confirms the service is on a published tag. Why: The slot only withheld the action on failure, so during the request a service pinned to a prerelease still offered it. In flight the console knows exactly as little as it does on failure, and this is not a brief window — the endpoint reads catalog.json plus two manifests from GitHub before answering, and the pin it may be about to reveal is a tag that disappears when its pull request closes. Notes: - This does not bring back the delay fixed in the previous commit: the version is local data and still paints with the list. Only the action waits. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
rmnbrd
requested changes
Aug 27, 2026
What: Rename the `useErrorBoundary` prop to `throwOnError`, move `useBlueprintUpdateState` into its own folder under `hooks/`, and rename `BlueprintHelmVersionSlot` to `BlueprintChartVersionSlot`. Why: - `use` is React's prefix for hooks, and the prop is not one. `throwOnError` is also what react-query calls the same option from v5 on, so the rename lines up with the eventual upgrade. It still maps to `useErrorBoundary` at the useQuery call, which is v4's name for it. - The hook was declared inline in a cell component, where the repo keeps every other hook in `hooks/<name>/<name>.ts` and exports it from the lib index. - "Helm" read as the catalog's `HELM/` provider directory, which is not what selects this path: q-core derives the service type from the manifest's engine spec (Blueprint.serviceTypeFrom), so a blueprint under any provider whose qbm.yml declares a helm engine produces a Helm service and lands here. The component renders a chart version, which is what its name now says, and the comment states the actual rule. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
All reported issues were addressed across 6 files (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Fix all with cubic | Re-trigger cubic
…ailing What: Drop the cached update response once the check errors, resolve the tag from the service's own pinned branch in that state, and route the overview header through the same hook instead of reading the query directly. Why: react-query keeps the last successful `data` when a refetch fails (query.js reducer spreads state on 'error'), so a service kept answering from the tag it used to be on. `update-service-rc` repoints a live service onto a prerelease tag the catalog cannot resolve, which is exactly the case that then 404s on the next background refetch: the stale `current_tag` masked the prerelease branch, so the service under test showed no RC badge and kept an "Update available" action pointing at a `latest_tag` computed for a tag it is no longer on. Notes: - The overview header had the same exposure through its own `useBlueprintUpdate` call. Sharing the hook keeps the rule in one place rather than repeating a subtle guard at each call site. - The hook now returns the resolved tag, so the version keeps rendering off the pinned branch when the check cannot answer, instead of disappearing with the dropped response. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
All reported issues were addressed across 5 files (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Fix all with cubic | Re-trigger cubic
What:
Add `isBlueprintTag` and gate the local-tag fallback on it, so a branch that is
not `{PROVIDER}/{service}/{major}/{version}` is ignored rather than read.
Why:
Both tag accessors are positional — `getBlueprintServiceVersion` takes the
second-to-last segment — so a three-segment branch such as `AWS/s3/1.2.3` would
have rendered `vs3`, and a plain branch name would have rendered the repository
owner. Wrong output is worse than none, and unlike `current_tag` the branch is
read off the service rather than handed over by an API that already validated
it. The shape checked here is the one q-core enforces before it will read a tag
at all.
Notes:
- This should not fire in practice: the engine writes the blueprint tag verbatim
as the branch, q-core rejects any tag that is not four segments, and the
console blocks editing the git source of a blueprint-backed service. The guard
is for when one of those stops holding.
- It covers the list cell as well as the header — both resolve their tag through
the same hook.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
rmnbrd
approved these changes
Aug 27, 2026
rmnbrd
left a comment
rmnbrd
left a comment
Contributor
There was a problem hiding this comment.
Tested and approved. LGTM ✅
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
3 participants
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.
Summary
Screenshots / Recordings
Testing
yarn testoryarn test -u(if you need to regenerate snapshots)yarn formatyarn lintPR Checklist
.cursor/rules)feat(service): add new Terraform service) - required for semantic-releaseSummary by cubic
Stops services pinned to unpublished prerelease blueprint tags from blanking the service overview or trusting a stale update check, and flags them with an "RC test" badge in the services table.
Bug Fixes
-pr{PR}.{sha}-rcmarker so a published1.2.3-rcrelease keeps its update badge.{PROVIDER}/{service}/{major}/{version}shape.throwOnErrorand moves the update-state hook underhooks/.Written for commit ed11a81. Summary will update on new commits.