Add DX cli support to multi-tenant environments

[christian-calabrese]

Summary

• Allow dx add environment to accept tenant-qualified names such as ced-prod and cgn-dev.
• Derive Azure short environment codes from the lifecycle suffix while keeping generated folders and GitHub environments tenant-qualified.
• Ensure repository-specific bootstrapper OIDC federated credentials and GitHub environment secrets are configured even when Azure bootstrap resources already exist.
• Document the multi-tenant workflow in the website and update the DX CLI companion skill for future agents.

Resolves CES-1753

[christian-calabrese]

[krusty93]

thought: I'm not sure removing the choice is the right thing. Potentially, users can use everything they want and our framework would probably break. Maybe would it better to add another option like add environment [--prefix cgn] --name prod?

[kin0992]

I agree, I would prefer to keep the choice and handle it differently. Can we reuse the already existing prefix flag?

[christian-calabrese]

I’d avoid reusing prefix as the tenant identifier because it only drives Azure resource naming, while the tenant must also disambiguate repo-level surfaces such as folders, workflows, GitHub environments, and Terraform state.

The current implementation does not accept arbitrary values unchecked: Commander no longer enforces choices, but the domain schema still only accepts dev|uat|prod or <tenant>-<env>.

That said, if we want to preserve the --name dev|uat|prod contract, I think the cleaner alternative is adding a first-class --tenant cgn option and deriving the logical environment as cgn-prod, rather than overloading --prefix.

[mamu0]

What if we used a format similar to what the CLI already uses for the GitHub App?
We wouldn't add any new inputs, it would remain just dev/uat/prod, but the CLI could display a prompt like "Do you want to add a tenant? (y/n)" and, if confirmed, ask you to enter it.

[krusty93]

The current implementation does not accept arbitrary values unchecked: Commander no longer enforces choices, but the domain schema still only accepts dev|uat|prod or -.

How did this information come back to the user/agent? Should we update the companion skill too?

btw @mamu0 proposed an interesting option

[kin0992]

note: to maximise agentic experience, we should not ask for confirmations, but instead pass a flag

[dx-release-internal]

⚠️ Missing Nx Version Plan

Nx Release reports that this PR has touched projects without version plan coverage.

Run pnpm nx release plan and add the generated version plans.

Nx Plan Check result:

NX   Touched projects based on changed files

  - docs
  - @pagopa/dx-cli

NOTE: You can adjust your "versionPlans.ignorePatternsForPlanCheck" config to stop certain files from resulting in projects being classed as touched for the purposes of this command.


 NX   Project "@pagopa/dx-cli" has pending bumps in version plan(s)

  - "minor" in version-plan-1784551273866.md


 NX   Project "renew-tls-certificate" has pending bumps in version plan(s)

  - "patch" in version-plan-1785250247375.md


 NX   Project "@pagopa/docker-build-push" has pending bumps in version plan(s)

  - "patch" in version-plan-1785250247375.md



 NX   Touched projects missing version plans

The following touched projects do not feature in any version plan files:
  - docs

Please use `nx release plan` to generate missing version plans, or adjust your "versionPlans.ignorePatternsForPlanCheck" config stop certain files from affecting the projects for the purposes of this command.

Run with --verbose to see the full list of changed files used for the touched projects logic.

This comment is managed automatically by Nx Release. Version plan guide

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://proud-mud-0405c6703-2002.westeurope.1.azurestaticapps.net