CLI-547 Experiment with a new agentic workflow by damien-urruty-sonarsource · Pull Request #350 · SonarSource/sonarqube-cli

damien-urruty-sonarsource · 2026-06-01T12:54:18Z

Summary by Gitar

New Agentic Workflow:
- Implemented night-owl agentic workflow for automated Jira ticket processing.
- Added prepare-jira-context.sh to automate Atlassian CLI authentication and Jira context gathering.
- Created night-owl.md and night-owl.lock.yml to define the new workflow architecture.
Workflow Migration:
- Refactored ci-failure-triage-agent to align with the new night-owl concurrency patterns and operational standards.
Documentation:
- Updated CLAUDE.md with guidelines and instructions for implementing the new agentic workflow.

_{This will update automatically on new commits.}

hashicorp-vault-sonar-prod · 2026-06-01T12:54:40Z

gitar-bot · 2026-06-01T12:56:22Z

-
-concurrency: ci-triage-${{ github.run_id }}
+
+concurrency: night-owl


💡 Quality: ci-failure-triage-agent.md fully repurposed but keeps old name

The ci-failure-triage-agent.md workflow has been entirely replaced with the Night Owl logic (identical env vars, prompt, safe-outputs). This means the original CI failure triage functionality is lost. The workflow file name, the GitHub Actions name: field ("CI Failure Triage Agent"), and the run-name in the lock file are now misleading. Consider either:

Keeping the CI failure triage agent intact and only adding the new night-owl.md workflow, or

Renaming/removing the old file to avoid confusion.

The comment on line 124 says it's "temporarily repurposed", but having two identically-functioning workflows (night-owl.md and ci-failure-triage-agent.md) with the same concurrency group (night-owl) and the same cron schedule could cause unintended mutual cancellation.

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

sonarqubecloud · 2026-06-03T17:41:06Z

Agentic Analysis: Early Results

Agentic Analysis and Context Augmentation are available on your project. Here are some issues that could have been prevented. Follow the links to learn how to put them into action.

19 issue(s) found across 1 file(s):

Rule	File	Line	Message
`shelldre:S7679`	`.github/scripts/night-owl/prepare-jira-context.sh`	14	Assign this positional parameter to a local variable.
`shelldre:S7679`	`.github/scripts/night-owl/prepare-jira-context.sh`	14	Assign this positional parameter to a local variable.
`shelldre:S7679`	`.github/scripts/night-owl/prepare-jira-context.sh`	73	Assign this positional parameter to a local variable.
`shelldre:S7679`	`.github/scripts/night-owl/prepare-jira-context.sh`	80	Assign this positional parameter to a local variable.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	83	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	132	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	169	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	176	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	201	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	204	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	207	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	214	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	293	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	314	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	334	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	335	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	359	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	382	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.
`shelldre:S7688`	`.github/scripts/night-owl/prepare-jira-context.sh`	417	Use '[[' instead of '[' for conditional tests. The '[[' construct is safer and more feature-rich.

_{Analyzed by SonarQube Agentic Analysis in 3.5 s}

gitar-bot · 2026-06-03T17:45:40Z

+issue_description_text() {
+  local issue_json="$1"
+  local description_text
+
+  description_text="$(
+    jq '.fields.description // .description // null' <<<"$issue_json" | adf_to_text
+  )"
+
+  if [ -n "$(compact_text "$description_text")" ]; then
+    printf '%s\n' "$description_text"
+  else
+    printf '_None provided._\n'
+  fi
+}


💡 Security: Untrusted Jira content injected verbatim into autonomous agent prompt

prepare-jira-context.sh builds context_markdown from Jira ticket summary, description, comments, and linked-issue fields (issue_description_text/format_comments_markdown/format_links_markdown) and emits it to GITHUB_OUTPUT. Both night-owl.md and ci-failure-triage-agent.md then inline ${{ needs.night_owl_prepare.outputs.context_markdown }} directly into the agent prompt and instruct the agent to 'Treat the prepared Jira content above as the source of truth.' The agent has the create_pull_request safe output, so a Jira ticket (any CLI ticket labeled for-agent) whose description/comments contain adversarial instructions becomes an XPIA / prompt-injection vector that can steer autonomous code changes and PRs.

This is partially mitigated by the gh-aw xpia.md guard prompt, and the surface is not strictly new (Jira was previously read via MCP). However, the change moves the content into the static prompt body rather than tool results. Consider: (1) clearly delimiting the Jira content as untrusted data in the prompt rather than 'source of truth', and (2) tightening the agent job's firewall — it still allows api.atlassian.com / sonarsource.atlassian.net even though the agent no longer needs Jira access (the prepare job does), so those domains are unnecessary egress/exfiltration surface for the agent.

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

gitar-bot · 2026-06-03T17:45:41Z

+has_open_pr_for_key() {
+  local key="$1"
+  local pattern="(^|[^A-Z0-9])${key}([^A-Z0-9]|$)"
+
+  jq -e --arg pattern "$pattern" '
+    any(
+      .[]?;
+      ([.title // "", .body // "", .headRefName // ""] | join("\n")) | test($pattern; "i")
+    )
+  ' <<<"$OPEN_PULL_REQUESTS_JSON" >/dev/null
+}


💡 Edge Case: Open-PR dedup capped at 100 PRs and relies on exact key text match

OPEN_PULL_REQUESTS_JSON is fetched with gh pr list --state open --limit 100, and has_open_pr_for_key only matches the Jira key as a token in title/body/headRefName. If a repository has more than 100 open PRs, an in-flight ticket may not be found and Night Owl could start duplicate work on a ticket already covered by an open PR. The match also fails entirely if a previous night-owl PR did not embed the Jira key in its title/body/branch. Consider raising/removing the limit (or filtering by the night-owl label/author) and ensuring created PRs always embed the Jira key.

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

gitar-bot · 2026-06-03T17:45:42Z

+    --json number,title,body,headRefName,url
+)"
+
+SEARCH_RESULTS_JSON="$(search_workitems)"


💡 Quality: Malformed acli search output is silently reported as 'starving'

The candidate loop is fed by a process substitution: done < <(normalize_collection <<<"$SEARCH_RESULTS_JSON" | jq -c '.[]?'). With set -euo pipefail, a failure inside a process substitution does not abort the parent shell. If acli ... search returns output that is not valid JSON (or an unexpected shape normalize_collection cannot match), the pipeline fails/produces nothing, the loop iterates zero times, candidate_count stays 0, and the script emits a 'No Jira ticket matched' starving Slack message and exits 0 — masking an actual infrastructure/query error as routine starvation. Consider validating SEARCH_RESULTS_JSON parses as JSON (e.g. jq empty with explicit error handling) before the loop so genuine failures route to night_owl_prepare_failure_notify instead of the starving path.

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

gitar-bot · 2026-06-03T21:04:28Z

Code Review 👍 Approved with suggestions 1 resolved / 5 findings

Introduces the night-owl agentic workflow for Jira ticket processing and refactors CI triage infrastructure. Rename the repurposed ci-failure-triage-agent.md, sanitize Jira content before injection, and improve pull request deduplication logic for robustness.

💡 Quality: ci-failure-triage-agent.md fully repurposed but keeps old name

The ci-failure-triage-agent.md workflow has been entirely replaced with the Night Owl logic (identical env vars, prompt, safe-outputs). This means the original CI failure triage functionality is lost. The workflow file name, the GitHub Actions name: field ("CI Failure Triage Agent"), and the run-name in the lock file are now misleading. Consider either:

Keeping the CI failure triage agent intact and only adding the new night-owl.md workflow, or
Renaming/removing the old file to avoid confusion.

The comment on line 124 says it's "temporarily repurposed", but having two identically-functioning workflows (night-owl.md and ci-failure-triage-agent.md) with the same concurrency group (night-owl) and the same cron schedule could cause unintended mutual cancellation.

💡 Security: Untrusted Jira content injected verbatim into autonomous agent prompt

📄 .github/scripts/night-owl/prepare-jira-context.sh:124-137 📄 .github/scripts/night-owl/prepare-jira-context.sh:151-165 📄 .github/scripts/night-owl/prepare-jira-context.sh:183-197 📄 .github/scripts/night-owl/prepare-jira-context.sh:434-446 📄 .github/workflows/night-owl.md:200 📄 .github/workflows/night-owl.md:217-219 📄 .github/workflows/night-owl.lock.yml:805

prepare-jira-context.sh builds context_markdown from Jira ticket summary, description, comments, and linked-issue fields (issue_description_text/format_comments_markdown/format_links_markdown) and emits it to GITHUB_OUTPUT. Both night-owl.md and ci-failure-triage-agent.md then inline ${{ needs.night_owl_prepare.outputs.context_markdown }} directly into the agent prompt and instruct the agent to 'Treat the prepared Jira content above as the source of truth.' The agent has the create_pull_request safe output, so a Jira ticket (any CLI ticket labeled for-agent) whose description/comments contain adversarial instructions becomes an XPIA / prompt-injection vector that can steer autonomous code changes and PRs.

This is partially mitigated by the gh-aw xpia.md guard prompt, and the surface is not strictly new (Jira was previously read via MCP). However, the change moves the content into the static prompt body rather than tool results. Consider: (1) clearly delimiting the Jira content as untrusted data in the prompt rather than 'source of truth', and (2) tightening the agent job's firewall — it still allows api.atlassian.com / sonarsource.atlassian.net even though the agent no longer needs Jira access (the prepare job does), so those domains are unnecessary egress/exfiltration surface for the agent.

💡 Edge Case: Open-PR dedup capped at 100 PRs and relies on exact key text match

📄 .github/scripts/night-owl/prepare-jira-context.sh:139-149 📄 .github/scripts/night-owl/prepare-jira-context.sh:274-280

OPEN_PULL_REQUESTS_JSON is fetched with gh pr list --state open --limit 100, and has_open_pr_for_key only matches the Jira key as a token in title/body/headRefName. If a repository has more than 100 open PRs, an in-flight ticket may not be found and Night Owl could start duplicate work on a ticket already covered by an open PR. The match also fails entirely if a previous night-owl PR did not embed the Jira key in its title/body/branch. Consider raising/removing the limit (or filtering by the night-owl label/author) and ensuring created PRs always embed the Jira key.

💡 Quality: Malformed acli search output is silently reported as 'starving'

📄 .github/scripts/night-owl/prepare-jira-context.sh:282 📄 .github/scripts/night-owl/prepare-jira-context.sh:289 📄 .github/scripts/night-owl/prepare-jira-context.sh:332 📄 .github/scripts/night-owl/prepare-jira-context.sh:334-338

The candidate loop is fed by a process substitution: done < <(normalize_collection <<<"$SEARCH_RESULTS_JSON" | jq -c '.[]?'). With set -euo pipefail, a failure inside a process substitution does not abort the parent shell. If acli ... search returns output that is not valid JSON (or an unexpected shape normalize_collection cannot match), the pipeline fails/produces nothing, the loop iterates zero times, candidate_count stays 0, and the script emits a 'No Jira ticket matched' starving Slack message and exits 0 — masking an actual infrastructure/query error as routine starvation. Consider validating SEARCH_RESULTS_JSON parses as JSON (e.g. jq empty with explicit error handling) before the loop so genuine failures route to night_owl_prepare_failure_notify instead of the starving path.

✅ 1 resolved

✅ Security: Credentials in job output not masked with add-mask

📄 .github/workflows/night-owl.md:64-65 📄 .github/workflows/ci-failure-triage-agent.md:64-65
The atlassian_mcp_auth job writes Base64-encoded Jira credentials directly to $GITHUB_OUTPUT without first calling ::add-mask::. GitHub Actions does not automatically mask job outputs, so the authorization_header value (which is just Basic <base64(user:token)>) could appear in plain text in workflow logs of downstream jobs that reference it. Adding ::add-mask:: before writing the output ensures the value is redacted from all logs.

🤖 Prompt for agents

Code Review: Introduces the night-owl agentic workflow for Jira ticket processing and refactors CI triage infrastructure. Rename the repurposed `ci-failure-triage-agent.md`, sanitize Jira content before injection, and improve pull request deduplication logic for robustness.

1. 💡 Quality: ci-failure-triage-agent.md fully repurposed but keeps old name
   Files: .github/workflows/ci-failure-triage-agent.md:7, .github/workflows/ci-failure-triage-agent.md:122-124, .github/workflows/ci-failure-triage-agent.lock.yml:73, .github/workflows/ci-failure-triage-agent.md, .github/workflows/ci-failure-triage-agent.lock.yml:59, .github/workflows/ci-failure-triage-agent.lock.yml:61-62, .github/workflows/night-owl.lock.yml:61-62, .github/workflows/night-owl.lock.yml:73, .github/workflows/ci-failure-triage-agent.md:3-4, .github/workflows/night-owl.md:3-4, .github/workflows/night-owl.md:7

   The `ci-failure-triage-agent.md` workflow has been entirely replaced with the Night Owl logic (identical env vars, prompt, safe-outputs). This means the original CI failure triage functionality is lost. The workflow file name, the GitHub Actions `name:` field ("CI Failure Triage Agent"), and the `run-name` in the lock file are now misleading. Consider either:
   - Keeping the CI failure triage agent intact and only adding the new `night-owl.md` workflow, or
   - Renaming/removing the old file to avoid confusion.
   
   The comment on line 124 says it's "temporarily repurposed", but having two identically-functioning workflows (`night-owl.md` and `ci-failure-triage-agent.md`) with the same concurrency group (`night-owl`) and the same cron schedule could cause unintended mutual cancellation.

2. 💡 Security: Untrusted Jira content injected verbatim into autonomous agent prompt
   Files: .github/scripts/night-owl/prepare-jira-context.sh:124-137, .github/scripts/night-owl/prepare-jira-context.sh:151-165, .github/scripts/night-owl/prepare-jira-context.sh:183-197, .github/scripts/night-owl/prepare-jira-context.sh:434-446, .github/workflows/night-owl.md:200, .github/workflows/night-owl.md:217-219, .github/workflows/night-owl.lock.yml:805

   `prepare-jira-context.sh` builds `context_markdown` from Jira ticket summary, description, comments, and linked-issue fields (issue_description_text/format_comments_markdown/format_links_markdown) and emits it to GITHUB_OUTPUT. Both `night-owl.md` and `ci-failure-triage-agent.md` then inline `${{ needs.night_owl_prepare.outputs.context_markdown }}` directly into the agent prompt and instruct the agent to 'Treat the prepared Jira content above as the source of truth.' The agent has the `create_pull_request` safe output, so a Jira ticket (any CLI ticket labeled `for-agent`) whose description/comments contain adversarial instructions becomes an XPIA / prompt-injection vector that can steer autonomous code changes and PRs.
   
   This is partially mitigated by the gh-aw `xpia.md` guard prompt, and the surface is not strictly new (Jira was previously read via MCP). However, the change moves the content into the static prompt body rather than tool results. Consider: (1) clearly delimiting the Jira content as untrusted data in the prompt rather than 'source of truth', and (2) tightening the agent job's firewall — it still allows `api.atlassian.com` / `sonarsource.atlassian.net` even though the agent no longer needs Jira access (the prepare job does), so those domains are unnecessary egress/exfiltration surface for the agent.

3. 💡 Edge Case: Open-PR dedup capped at 100 PRs and relies on exact key text match
   Files: .github/scripts/night-owl/prepare-jira-context.sh:139-149, .github/scripts/night-owl/prepare-jira-context.sh:274-280

   `OPEN_PULL_REQUESTS_JSON` is fetched with `gh pr list --state open --limit 100`, and `has_open_pr_for_key` only matches the Jira key as a token in title/body/headRefName. If a repository has more than 100 open PRs, an in-flight ticket may not be found and Night Owl could start duplicate work on a ticket already covered by an open PR. The match also fails entirely if a previous night-owl PR did not embed the Jira key in its title/body/branch. Consider raising/removing the limit (or filtering by the night-owl label/author) and ensuring created PRs always embed the Jira key.

4. 💡 Quality: Malformed acli search output is silently reported as 'starving'
   Files: .github/scripts/night-owl/prepare-jira-context.sh:282, .github/scripts/night-owl/prepare-jira-context.sh:289, .github/scripts/night-owl/prepare-jira-context.sh:332, .github/scripts/night-owl/prepare-jira-context.sh:334-338

   The candidate loop is fed by a process substitution: `done < <(normalize_collection <<<"$SEARCH_RESULTS_JSON" | jq -c '.[]?')`. With `set -euo pipefail`, a failure inside a process substitution does not abort the parent shell. If `acli ... search` returns output that is not valid JSON (or an unexpected shape `normalize_collection` cannot match), the pipeline fails/produces nothing, the loop iterates zero times, `candidate_count` stays 0, and the script emits a 'No Jira ticket matched' starving Slack message and exits 0 — masking an actual infrastructure/query error as routine starvation. Consider validating `SEARCH_RESULTS_JSON` parses as JSON (e.g. `jq empty` with explicit error handling) before the loop so genuine failures route to `night_owl_prepare_failure_notify` instead of the starving path.

Options

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

Comment with these commands to change:

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

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

sonarqubecloud · 2026-06-03T21:14:51Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

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

See analysis details on SonarQube Cloud

damien-urruty-sonarsource temporarily deployed to sca-checking June 1, 2026 12:54 — with GitHub Actions Inactive

hashicorp-vault-sonar-prod Bot changed the title ~~Experiment with a new agentic workflow~~ CLI-547 Experiment with a new agentic workflow Jun 1, 2026

gitar-bot Bot reviewed Jun 1, 2026

View reviewed changes

Comment thread .github/workflows/night-owl.md Outdated

gitar-bot Bot reviewed Jun 1, 2026

View reviewed changes

Experiment with a new agentic workflow

e5d065d

damien-urruty-sonarsource force-pushed the task/dam/night-owl branch from 10a4170 to e5d065d Compare June 1, 2026 12:58

damien-urruty-sonarsource temporarily deployed to sca-checking June 1, 2026 12:58 — with GitHub Actions Inactive

github-actions Bot mentioned this pull request Jun 1, 2026

[aw] CI Failure Triage Agent failed #351

Closed

Try different API

2fea86c

damien-urruty-sonarsource temporarily deployed to sca-checking June 3, 2026 17:02 — with GitHub Actions Inactive

github-actions Bot mentioned this pull request Jun 3, 2026

[aw] CI Failure Triage Agent failed #371

Closed

damien-urruty-sonarsource temporarily deployed to sca-checking June 3, 2026 17:41 — with GitHub Actions Inactive

damien-urruty-sonarsource force-pushed the task/dam/night-owl branch from a9de2cd to 736b187 Compare June 3, 2026 17:43

damien-urruty-sonarsource temporarily deployed to sca-checking June 3, 2026 17:44 — with GitHub Actions Inactive

gitar-bot Bot reviewed Jun 3, 2026

View reviewed changes

damien-urruty-sonarsource force-pushed the task/dam/night-owl branch from 736b187 to 90d00f1 Compare June 3, 2026 17:50

damien-urruty-sonarsource temporarily deployed to sca-checking June 3, 2026 17:50 — with GitHub Actions Inactive

damien-urruty-sonarsource force-pushed the task/dam/night-owl branch from 90d00f1 to 667136a Compare June 3, 2026 17:52

damien-urruty-sonarsource temporarily deployed to sca-checking June 3, 2026 17:52 — with GitHub Actions Inactive

damien-urruty-sonarsource force-pushed the task/dam/night-owl branch from 667136a to 7405032 Compare June 3, 2026 18:17

damien-urruty-sonarsource temporarily deployed to sca-checking June 3, 2026 18:17 — with GitHub Actions Inactive

Try CLI

9ca58e9

damien-urruty-sonarsource force-pushed the task/dam/night-owl branch from 7405032 to 9ca58e9 Compare June 3, 2026 21:03

damien-urruty-sonarsource temporarily deployed to sca-checking June 3, 2026 21:03 — with GitHub Actions Inactive

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CLI-547 Experiment with a new agentic workflow#350

CLI-547 Experiment with a new agentic workflow#350
damien-urruty-sonarsource wants to merge 3 commits into
masterfrom
task/dam/night-owl

damien-urruty-sonarsource commented Jun 1, 2026 •

edited by gitar-bot Bot

Loading

Uh oh!

hashicorp-vault-sonar-prod Bot commented Jun 1, 2026 •

edited by atlassian Bot

Loading

Uh oh!

Uh oh!

gitar-bot Bot Jun 1, 2026

Uh oh!

sonarqubecloud Bot commented Jun 3, 2026 •

edited

Loading

Uh oh!

gitar-bot Bot Jun 3, 2026

Uh oh!

gitar-bot Bot Jun 3, 2026

Uh oh!

gitar-bot Bot Jun 3, 2026

Uh oh!

gitar-bot Bot commented Jun 3, 2026

Uh oh!

sonarqubecloud Bot commented Jun 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant


		concurrency: ci-triage-${{ github.run_id }}

		concurrency: night-owl

Conversation

damien-urruty-sonarsource commented Jun 1, 2026 • edited by gitar-bot Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by Gitar

Uh oh!

hashicorp-vault-sonar-prod Bot commented Jun 1, 2026 • edited by atlassian Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

gitar-bot Bot Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud Bot commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Agentic Analysis: Early Results

Uh oh!

gitar-bot Bot Jun 3, 2026

Choose a reason for hiding this comment

Uh oh!

gitar-bot Bot Jun 3, 2026

Choose a reason for hiding this comment

Uh oh!

gitar-bot Bot Jun 3, 2026

Choose a reason for hiding this comment

Uh oh!

gitar-bot Bot commented Jun 3, 2026

Uh oh!

sonarqubecloud Bot commented Jun 3, 2026

Quality Gate passed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

damien-urruty-sonarsource commented Jun 1, 2026 •

edited by gitar-bot Bot

Loading

hashicorp-vault-sonar-prod Bot commented Jun 1, 2026 •

edited by atlassian Bot

Loading

sonarqubecloud Bot commented Jun 3, 2026 •

edited

Loading