chore(release): promote staging to production - #2915
Merged
Merged
Conversation
* feat(agent-task): add workflow scheduling * fix(agent-task): align schedule form states * fix(agent-task): group schedule with service information
* feat(terraform): add environment variables to creation flow * fix(terraform): make creation retries safe * fix(terraform): resume creation from completed steps * fix(terraform): reconcile creation retries * fix(terraform): surface retry update errors * fix(terraform): narrow service payload type * fix(terraform): allow empty environment variables * fix(terraform): align environment variables step * fix(terraform): space environment variable sections * fix(terraform): group environment variable heading * fix(terraform): show creation progress * fix(terraform): restore creation button feedback * fix(terraform): rename summary variables section * fix(terraform): skip empty variable import * fix(job): allow empty creation variables * fix(terraform): create environment variables directly * fix(terraform): use shared variable import
* 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>
* 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>
* 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>
* 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>
* 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>
* fix(blueprint): stop trusting a cached update check after it starts failing
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>
* 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>
---------
Co-authored-by: Rémi Bonnet <bonnet.rem@gmail.com>
Co-authored-by: Rémi Bonnet <rbonnet@qovery.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Member
Author
|
🎉 This PR is included in version 1.345.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2915 +/- ##
==========================================
+ Coverage 46.70% 48.49% +1.78%
==========================================
Files 507 1303 +796
Lines 13749 28117 +14368
Branches 4184 8215 +4031
==========================================
+ Hits 6421 13634 +7213
- Misses 6203 12187 +5984
- Partials 1125 2296 +1171
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:
|
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
2 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.
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.
Summary by cubic
Opens the production promotion path from
stagingtomain. Merging this PR triggers semantic-release, then the existing production deployment workflow.Use a merge commit, not squash, so the original conventional commits are preserved for semantic-release.
Includes
qovery-typescript-axiosbumped to1.1.962.Written for commit 1feda76. Summary will update on new commits.