GROW-213 Provision SonarQube project in sonar import command

[kevinmlsilva]

Summary

• Wires up the final step of sonar import: after org/repo selection, creates the bound SonarQube project via the provision_projects API and prints its project key.
• Resolves the org's connected DevOps platform to format the installationKeys param correctly (<slug>|<id> for GitHub, plain id otherwise).
• Enforces the org's public/private project visibility rules (onlyPrivateProjects + billing entitlement) before provisioning, rejecting mismatched repos.
• Already-imported repos are filtered out of the interactive picker instead of just labeled; fails clearly if none remain to import.
• Command remains hidden while in development.

Continuation of GROW-212.

Test plan

• bun run typecheck
• bun run lint
• bun test tests/integration/specs/import/import.test.ts (29 pass, including new provisioning/visibility test cases)

JIRA: GROW-213

[netlify]

✅ Deploy Preview for sonarqube-cli canceled.

Name	Link
🔨 Latest commit	8e830a7
🔍 Latest deploy log	https://app.netlify.com/projects/sonarqube-cli/deploys/6a4cf026b2ee930008118f38

[hashicorp-vault-sonar-prod]

GROW-213

[gitar-bot]

Code Review ✅ Approved 2 resolved / 2 findings

Wires the final project provisioning step into the sonar import command, addressing visibility rule enforcement and redundant API fetching. Integration tests verify correct handling of repo selection and visibility constraints.

✅ 2 resolved

✅ Bug: Interactive repo picker ignores visibility rules (disabled flag no-op)

📄 src/cli/commands/import/_common/resolve-options.ts:237-251
In resolveRepo's interactive path, each option is built with disabled: !isRepoSelectable(repo, onlyPrivateProjects). However, selectPrompt/SelectOption (src/ui/components/prompts.ts) has no disabled field and no logic that skips or blocks disabled entries — the property is silently dropped. As a result the onlyPrivateProjects visibility rule is NOT enforced in interactive mode: a user can navigate to and select a repo whose visibility is disallowed (e.g. a public repo in a private-only org, or vice-versa). This contradicts the explicit --repo fast path (lines 189-193), which throws CommandFailedError for the same mismatch. The selected repo then proceeds straight to provisionProject, relying on a server-side rejection rather than the intended client-side guard.

Either the prompt needs real disabled-option support, or resolveRepo should re-validate the chosen repo (or filter non-selectable repos out and error when none remain), mirroring the --repo behavior.

✅ Quality: resolveOrg's almKey is fetched but never used; refetched via API

📄 src/cli/commands/import/index.ts:35 📄 src/cli/commands/import/index.ts:39 📄 src/cli/commands/import/_common/resolve-options.ts:129-137
resolveOrg populates ResolvedOrg.almKey from org.alm?.key for the interactive path, but importHandler destructures only { key, onlyPrivateProjectsEnabled } and always calls client.getOrganizationAlmKey(orgKey) — an extra getOrganizationLegacyId + organization-bindings round trip — even when the ALM key was already known from the org listing. This is a redundant network call and leaves the almKey field effectively dead in this code path. Consider using the already-resolved almKey when present and only falling back to getOrganizationAlmKey for the --org path where it is undefined.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
89.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud