CLI-9 integrate pre commit hook

[sophio-japharidze-sonarsource]

No description provided.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 16 changed files in this pull request and generated 6 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[sonar-review-alpha]

Summary

This PR adds a new sonar integrate git command that installs git hooks for secret scanning before commit or push operations. The command supports:

• Hook types: pre-commit (scan staged files) or pre-push (scan unpushed commits)
• Installation scopes: per-repository or globally (via core.hooksPath)
• Multiple frameworks: native git hooks, Husky, or pre-commit framework with automatic detection
• Modes: interactive with prompts or non-interactive with --non-interactive flag

The implementation reuses existing secret-scanning logic, adds comprehensive test coverage (integration + unit tests), and updates CI/CD to install libsecret dependency on Linux.

What reviewers should know

Start here:

• src/cli/commands/integrate/git/index.ts (311 lines) — main command entry point with option parsing and orchestration

Hook installation strategies (review in order of implementation complexity):

1. git-shell-fragments.ts — raw bash/shell script generation; see HOOK_MARKER for how sonar hooks are identified for safe overwriting
2. git-husky.ts — delegates to Husky framework if detected
3. git-precommit-framework.ts — delegates to pre-commit framework if detected

Key decisions to watch:

• The command auto-detects which hook framework exists (native/.git/hooks, Husky, pre-commit) and installs accordingly — see detectSonarHookInstallation()
• The --force flag allows overwriting non-sonar hooks; the HOOK_MARKER string identifies sonar-installed hooks
• Global installation sets git config --global core.hooksPath — understand the security/compatibility implications
• Secret scanning reuses performSecretInstall() logic; trace how scan results block commits/pushes

Test coverage:

• tests/integration/specs/integrate/git.test.ts (344 lines) — full CLI integration scenarios
• tests/unit/integrate-git.test.ts (704 lines) — unit tests for framework detection and hook generation
• Look for libsecret dependency tests on Linux platforms

Gotchas:

• Multiple hook frameworks can coexist; ensure the detection logic properly prioritizes or handles overlap
• The --non-interactive mode must work correctly without user prompts (critical for CI/CD use)
• Cross-platform compatibility: hook scripts differ between shells; verify Windows/macOS/Linux paths

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonar-review-alpha]

Conclusion: Solid implementation overall with good framework detection and test coverage, but there's a bug in the global cancellation path that needs fixing before merge.

🗣️ Give feedback

[sonar-review-alpha]

Conclusion: The production-code fix for the global-cancellation exit-code bug is correct, but the test rewrite in this commit is broken — it silently discards the assertion and always passes. That needs to be corrected before merge. The shell-fragments duplication flagged in the previous review also remains open.

🗣️ Give feedback

[damien-urruty-sonarsource]

A first round of comments, I will try the feature now

[sonar-review-alpha]

Conclusion: Two of the three previously flagged issues remain unaddressed — the broken test that never evaluates its assertion, and the shell-fragment logic duplication. The cancellation exit-code fix is in.

SonarCloud recommendations: The token at index.ts:154 (sqp_b4556a16fa2d28519d2451a911d2e073024010bc) is intentionally embedded as example content to help users verify the hook, so SonarCloud is technically right to flag its format — but the concern here is whether this token was ever live. If it was generated from a real SonarQube instance, it must be revoked before this PR merges. If it was hand-crafted to look realistic, a comment on the constant saying so would both document intent and allow SonarCloud to be silenced as a false positive.

🗣️ Give feedback

[sonar-review-alpha]

Conclusion: The two issues from the previous review cycle remain unaddressed, and there is one additional broken test in the same describe block.

SonarCloud false positives: Both BLOCKERs flagging VERIFY_SECRET_CONTENT at src/cli/commands/integrate/git/index.ts:154 (AZz8eIuNoQXjdzAOWUm_ and AZzhihFTz7LVxbNF1k5G) are false positives. The sqp_b4556a16... string is a deliberately synthetic token used in the verification guide so users can confirm the hook catches secrets. It is not a real credential — dismiss both in SonarCloud.

🗣️ Give feedback

[sonar-review-alpha]

Conclusion: Solid implementation overall — the framework detection and three-path install strategy (pre-commit, Husky, raw git hooks) are well-structured and the test coverage looks thorough. Two logic duplication issues need fixing before merge.

SonarCloud recommendations: Even though index.ts:154 and index.ts are not failing the quality gate, I strongly recommend fixing them because VERIFY_SECRET_CONTENT embeds sqp_b4556a16fa2d28519d2451a911d2e073024010bc — a string that matches the real SonarQube token format. If this value was ever a real token it must be revoked immediately. Even if it was generated purely for this demo, shipping it in source means every downstream clone will contain it, and tools like truffleHog or GitHub secret scanning will flag it in perpetuity. Replace it with a clearly non-scannable placeholder (e.g. sqp_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX) or instruct the verification guide to generate the test file at runtime.

🗣️ Give feedback

[damien-urruty-sonarsource]

LGTM!

[sonarqubecloud]

SonarQube reviewer guide

Quality Gate passed

Issues
0 New issues
1 Accepted issue
0 Dependency risks

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

See analysis details on SonarQube Cloud