Overview - Console

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
2909
ed11a81c fix(blueprint): only read the pinned branch when it is shaped like a tag 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>
by Antoine
Succeeded
2909
6a4f53bc refactor(blueprint): address naming and placement review points 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>
by Antoine
Succeeded
2909
6a4f53bc refactor(blueprint): address naming and placement review points 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>
by Antoine
Succeeded
2909
ce16be03 fix(blueprint): withhold the helm deploy action while the update check 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>
by Antoine
Succeeded
2909
1d339075 fix(blueprint): stop the helm chart version waiting on the update check 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>
by Antoine
Succeeded
2909
734844b8 fix(blueprint): tighten prerelease detection and review follow-ups 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>
by Antoine
Succeeded
2909
1d714998 fix(blueprint): handle services pinned to an unpublished catalog tag 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>
by Antoine