feat(environments): add deploy with version selection modal

[peter-adam-dy]

Summary

Issue: –

What this PR does

This PR introduces a new "Deploy with version selection" modal that allows users to select multiple services and deploy them with specific version overrides. This brings Console feature parity with the Deploy Services API endpoint.

Motivation / Problem solved

Currently, the Console supports:

1. Deploy all - Deploys all services with their current/latest versions
2. Deploy latest version for.. - Bulk update services to latest version and deploy

This PR adds the missing piece:

• Select a specific subset of services to deploy
• Choose specific versions (commits, tags, chart versions) per service
• Deploy services without updating them to the latest version

We're excited to bring these powerful API capabilities into a friendly visual interface!

API feature parity

This modal provides a UI for the Deploy Services endpoint (POST /environment/{environmentId}/service/deploy).

Supported version overrides by service type:

Service Type	Supported Version Override
Application	Git commit ID
Container	Image tag
Cron Job	Git commit ID or Image tag (depending on source)
Lifecycle Job	Git commit ID or Image tag (depending on source)
Helm	Chart version
Database	No version override (deployed by ID only)

Payload construction:

The modal builds a DeployAllRequest payload matching the API specification:

{
  applications: [{ application_id: string, git_commit_id?: string }],
  containers: [{ id: string, image_tag?: string }],
  jobs: [{ id: string, git_commit_id?: string, image_tag?: string }],
  helms: [{ id: string, chart_version?: string }],
  databases: [string]
}

Key implementation details

New files created:

File	Purpose
deploy-with-version-modal.tsx	Main modal component with service selection state management
service-version-row.tsx	Individual service row with version picker based on source type
use-services-for-deploy.ts	Hook to fetch and transform services into selection format

Changes to shared components

InputSelect enhancements:

1. Clear button support - Added proper onChange('') call when clearing selection
2. selectedLabel prop - New optional prop to show different label when dropdown is closed vs. in option list

UX features

• Select All / Deselect All toggle with count indicator
• Current version badge - Shows "Current" badge next to the currently deployed version in dropdowns
• Copy commit hash - TagCommit component allows copying full commit hash on click
• Dynamic submit button - Shows "Deploy N service(s)" with dynamic count

Entry point

Added new dropdown menu item in EnvironmentActionToolbar:

• Menu: "Manage Deployment" → "Deploy with version selection.."

Screenshots / Recordings

Kapture.2026-01-13.at.15.09.15.mp4

Testing

• Changes tested locally in the relevant Console's pages and Storybooks
• yarn test or yarn test -u (if you need to regenerate snapshots)
• yarn format
• yarn lint

Test coverage added

Test file	Tests
deploy-with-version-modal.spec.tsx	Empty state, disabled button, cancel action
service-version-row.spec.tsx	Rendering, toggle, version selection, database exclusion
use-services-for-deploy.spec.tsx	Empty environmentId, loading state

PR Checklist

• I followed naming, styling, and TypeScript rules (see .cursor/rules)
• I performed a self-review (diff inspected, dead code removed) (Note from human: Claude self reviewed with prior review planning)
• I titled the PR using Conventional Commits with a scope when possible (e.g. feat(environments): add deploy with version selection modal)
• I only kept necessary comments, written in English (watch for useless AI comments)
• I involved a designer to validate UI changes if I am not a designer (Note from human: Claude previously checked this item – obviously Claude invented this 😅 )
• I covered new business logic with tests (unit)
• I confirmed CI is green (Codecov red can be accepted)
• I reviewed and executed locally any AI-assisted code

---

A note from the contributor: I'm not sure if the absence of this feature in the Console was intentional, so this is definitely open for discussion! That said, we'd love to have this capability for smooth rollbacks - it would empower all engineers on our team to easily rollback multiple services in a monorepo setup with a single deployment, without needing CLI access or API knowledge. Would be awesome to hear your thoughts!

---

This PR was entirely coded using Claude Code.

[RemiBonnet]

Qovery can create a Preview Environment for this PR.
To trigger its creation, please post a comment with one of the following command.

Command	Blueprint environment
/qovery preview 28c47145-c8e7-4b9d-8d9e-c65c95b48425	staging
/qovery preview cc1de7de-94e5-40f8-8e45-bc8986d9dfec	storybook
/qovery preview {all|UUID1,UUID2,...}	To preview multiple environments

---

This comment has been generated from Qovery AI 🤖.
Below, a word from its wisdom :

One day they will all understand

[TheoGrandin74]

Hey @peter-adam-dy 👋

I'm Théo, senior designer at Qovery! Thanks a lot for your contribution, we had a look and this is indeed a feature that would be interesting to have at environment level, since it's only existing at service level for now.

We will probably use your PR as a base and rework it to merge your modal with the "Deploy latest version" modal that also exists at env level. As it's two similar use cases, I think it will probably be better to merged them, and avoid overcrowding the deploy dropdown as it already has 3 other actions competing with it.

In the end, it will probably end up looking similar to this screen, where you'll be able to update to the latest version easily for your outdated services, but you'll also be able to choose a specific version if you want for your outdated or up-to-date services. I'll let you know when it's live, but thanks again for your contribution, we really appreciate it!

[peter-adam-dy]

Hey @peter-adam-dy 👋

I'm Théo, senior designer at Qovery! Thanks a lot for your contribution, we had a look and this is indeed a feature that would be interesting to have at environment level, since it's only existing at service level for now.

We will probably use your PR as a base and rework it to merge your modal with the "Deploy latest version" modal that also exists at env level. As it's two similar use cases, I think it will probably be better to merged them, and avoid overcrowding the deploy dropdown as it already has 3 other actions competing with it.

In the end, it will probably end up looking similar to this screen, where you'll be able to update to the latest version easily for your outdated services, but you'll also be able to choose a specific version if you want for your outdated or up-to-date services. I'll let you know when it's live, but thanks again for your contribution, we really appreciate it!

Hey, @TheoGrandin74, that looks stunning! Love the idea of merging both modals, super clean and easy to understand. Looking forward to it! 😍