feat(blueprints): add support for multiple versions#2791
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## staging #2791 +/- ##
===========================================
- Coverage 47.44% 47.09% -0.35%
===========================================
Files 1267 1177 -90
Lines 26812 25462 -1350
Branches 7913 7618 -295
===========================================
- Hits 12721 11992 -729
+ Misses 11892 11388 -504
+ Partials 2199 2082 -117
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:
|
There was a problem hiding this comment.
Pull request overview
This PR extends the blueprint-based service experience to support multiple blueprint versions by letting users select a version during creation and by surfacing blueprint update status in the service header.
Changes:
- Added a “Blueprint version” selector that sorts available major versions and sends the selected version tag in the create payload.
- Added an “Up to date” / “Update available” badge to the service overview header for blueprint-based services (with Suspense + skeleton loading state).
- Introduced a new
useBlueprintUpdateReact Query hook and corresponding query key in the services data-access layer.
Reviewed changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| libs/domains/services/feature/src/lib/service-overview/service-header/service-header.tsx | Adds blueprint update status badge (Suspense + skeleton) when blueprint_id is present. |
| libs/domains/services/feature/src/lib/service-overview/service-header/service-header.spec.tsx | Adds unit tests for up-to-date/outdated/loading states and non-blueprint behavior. |
| libs/domains/services/feature/src/lib/service-creation-flow/blueprint/blueprint-step-summary/blueprint-step-summary.tsx | Sends versionTag from form state as the blueprint tag in the create payload. |
| libs/domains/services/feature/src/lib/service-creation-flow/blueprint/blueprint-creation-utils/blueprint-creation-utils.ts | Adds sortBlueprintMajorVersions helper to order versions newest → oldest. |
| libs/domains/services/feature/src/lib/service-creation-flow/blueprint/blueprint-creation-utils/blueprint-creation-utils.spec.ts | Adds test coverage for sortBlueprintMajorVersions. |
| libs/domains/services/feature/src/lib/service-creation-flow/blueprint/blueprint-creation-flow.tsx | Tracks selected version tag, derives selected major version, and resets form fields when version changes. |
| libs/domains/services/feature/src/lib/service-creation-flow/blueprint/blueprint-creation-flow.spec.tsx | Adds test verifying sorting + selecting a version results in the expected create payload tag. |
| libs/domains/services/feature/src/lib/service-creation-flow/blueprint/blueprint-create-context/blueprint-create-context.ts | Extends form data with versionTag. |
| libs/domains/services/feature/src/lib/service-creation-flow/blueprint/blueprint-configuration-view/blueprint-configuration-view.tsx | Renders version selector (InputSelect) when multiple versions exist; falls back to read-only when only one. |
| libs/domains/services/feature/src/lib/hooks/use-blueprint-update/use-blueprint-update.ts | Adds useBlueprintUpdate hook wrapping queries.services.blueprintUpdate. |
| libs/domains/services/feature/src/index.ts | Exports the new useBlueprintUpdate hook. |
| libs/domains/services/data-access/src/lib/domains-services-data-access.ts | Adds services.blueprintUpdate query definition calling checkBlueprintUpdate. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| import { queries } from '@qovery/state/util-queries' | ||
|
|
||
| export interface UseBlueprintUpdateProps { | ||
| blueprintId?: string | null |
There was a problem hiding this comment.
| blueprintId?: string | null | |
| blueprintId: string |
From what I understand in the code, blueprintId should be always necessary?
| export function useBlueprintUpdate({ blueprintId, enabled = true, suspense = false }: UseBlueprintUpdateProps) { | ||
| return useQuery({ | ||
| ...queries.services.blueprintUpdate({ blueprintId: blueprintId ?? '' }), | ||
| enabled: enabled && Boolean(blueprintId), |
There was a problem hiding this comment.
| enabled: enabled && Boolean(blueprintId), | |
| enabled, |
| setSelectedVersionTag(watchedVersionTag) | ||
| }, [watchedVersionTag]) | ||
|
|
||
| useEffect(() => { |
There was a problem hiding this comment.
Can we avoid this sync effect?
It can reset the form with the previous version's fields before the new version's fields have loaded, then skip the reset once they arrive. I think resetting only after the selected version's fields are available would fix the stale-field issue
Blueprints: add support for multiple versions
This PR introduces 2 blueprint-related improvements:
Changes can be tested here and there.
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-release