Enable ymir todo trigger

[majamassarini]

When we use ymir_todo UX experience looks like these:

• https://redhat.atlassian.net/browse/RHEL-178234 ( the e2e was run 3 times here. The first one was failing on this error Do not needlessly create Z-Stream branch #543, the second one was failing on what should be fixed by commit Inject GITLAB_TOKEN auth header for pushes to the bot's fork namespace)
• https://redhat.atlassian.net/browse/RHEL-176681

[gemini-code-assist]

Code Review

This pull request replaces the global SILENT_RUN configuration with a silent-by-default model that can be bypassed per-issue using a new ymir_todo label, which initiates a user_triggered run. It also introduces atomic label swapping in the fetcher to prevent duplicate processing, increases the fetcher cron frequency to 5 minutes, and implements critical label write retries. Feedback on these changes highlights several key issues: the user_triggered flag is not propagated to downstream backport and rebase agents; the JQL query allows non-Red Hat employees to trigger runs on early adopter CVEs; immediate re-queuing on label-write failures can cause a tight infinite loop; and the fetcher's 10-minute active deadline exceeds its 5-minute cron interval, potentially blocking scheduled runs.

[majamassarini]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a maintainer-facing trigger label, ymir_todo, allowing Red Hat Employees to explicitly request end-to-end triage runs. It refactors the pipeline to be silent by default, suppressing intermediate failure labels and comments unless a run is user-triggered (user_triggered=True). The Jira Issue Fetcher is updated to atomically swap trigger labels for ymir_triage_in_progress before enqueuing tasks in Redis to prevent duplicate processing. Feedback on the changes identifies a high-severity bug where fresh issues with no Ymir labels are repeatedly enqueued due to an incorrect elif block. Additionally, improvements are suggested to safely handle potential null values in the Jira API responses (such as author, groups, and created fields) to prevent runtime exceptions, and to add an early return in set_jira_labels to avoid redundant API calls when no label updates are needed.

[majamassarini]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new maintainer-facing trigger label ymir_todo to initiate end-to-end runs on demand, replacing the global SILENT_RUN environment variable with a per-task user_triggered flag. When an issue is triggered via ymir_todo by a verified Red Hat Employee, the fetcher atomically swaps the label for ymir_triage_in_progress and enqueues it as user-triggered, which bypasses silence filters to post progress acknowledgments and result comments. Additionally, the fetcher's cron schedule is shortened to 5 minutes to process these requests promptly, and critical Jira label writes now include retry logic with exponential backoff to prevent duplicate processing. There are no review comments to assess, so I have no feedback to provide.

[majamassarini]

/gemini review

[gemini-code-assist]

Code Review

This pull request replaces the global SILENT_RUN environment variable with a per-issue, user-triggered workflow using a new ymir_todo label. When added by a verified Red Hat Employee, this label triggers end-to-end processing with active feedback (acknowledgements, results, and intermediate failure labels), while default runs remain silent. The fetcher atomically swaps trigger labels for ymir_triage_in_progress before enqueueing tasks to Redis. Feedback on these changes highlights two key issues: first, the triage agent's acknowledgement comment is posted prematurely and could be duplicated if subsequent critical label writes fail and the task is re-queued; second, expanding the changelog in the main issue API response is limited to 100 entries, which may cause author verification to fail on issues with long histories. It is recommended to move the acknowledgement comment after the successful label write and to use the dedicated paginated changelog endpoint.

[majamassarini]

/gemini review

[gemini-code-assist]

Code Review

This pull request replaces the global SILENT_RUN environment variable with a per-issue, user-triggered execution flow initiated by the ymir_todo label. The Jira issue fetcher now verifies that the ymir_todo label was added by a Red Hat Employee before atomically swapping it for ymir_triage_in_progress and enqueuing the task with a user_triggered flag. Agents are silent by default, suppressing comments and intermediate failure labels unless the run is user-triggered. Feedback on these changes highlights that the newly introduced _label_added_by_rh_employee method makes synchronous HTTP requests without retry or backoff mechanisms, which could cause transient network errors or rate limits to silently fail the verification. It is recommended to implement a retrying GET helper decorated with exponential backoff.

[majamassarini]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new maintainer-facing trigger label, ymir_todo, allowing Red Hat employees to explicitly request end-to-end runs on Jira issues. It replaces the global SILENT_RUN environment variable with a silent-by-default design, where user-facing comments and intermediate failure labels are suppressed unless a run is explicitly user_triggered (via ymir_todo). Additionally, the Jira issue fetcher now runs more frequently (every 5 minutes) and performs atomic label flips (ymir_todo / ymir_retry_needed to ymir_triage_in_progress) before enqueueing tasks to Redis to prevent duplicate processing. It also verifies that the ymir_todo label was added by a member of the "Red Hat Employee" group by paginating through the issue's changelog. There are no review comments to address, and the implementation is robust and well-tested.

[majamassarini]

/gemini review

[gemini-code-assist]

Code Review

This pull request replaces the global SILENT_RUN environment variable with a per-issue user_triggered flag (activated by the new ymir_todo label) to allow on-demand, verbose e2e runs. It updates the Jira Issue Fetcher to verify that the ymir_todo label was added by a Red Hat Employee, atomically flip trigger labels to ymir_triage_in_progress to prevent duplicate enqueues, and configures a new, more frequent CronJob for processing these manual requests. Additionally, git authentication was updated to support private GitLab forks under a custom FORK_NAMESPACE. Feedback on the changes highlights an issue in the fetcher's author verification logic where transient network or API errors are caught and treated as a non-employee action, which would incorrectly result in the silent deletion of the ymir_todo label; it is recommended to propagate and handle requests.RequestException as a transient failure to skip the issue without removing the label.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[majamassarini]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the pipeline's notification and execution model to be silent by default, introducing a new user-triggered workflow via the ymir_todo Jira label. The SILENT_RUN environment variable is removed in favor of a user_triggered flag propagated through tasks, which bypasses silence filters to post comments and intermediate failure labels. A new OpenShift CronJob is added to fetch ymir_todo issues promptly, verifying that the label was added by a Red Hat Employee. Additionally, the private GitLab helper is updated to support authentication for forks under a configured namespace. The review feedback correctly identifies a critical bug in the triage agent where writing a terminal error label prematurely would cause task retries to be skipped, and offers a robust improvement to handle potential typos in the FORK_NAMESPACE configuration.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[majamassarini]

/gemini review

[gemini-code-assist]

Code Review

This pull request replaces the SILENT_RUN environment variable with a default-silent behavior, introducing a new ymir_todo trigger label that allows Red Hat employees to opt into interactive runs with active feedback. The Jira Issue Fetcher is updated to atomically swap trigger labels for ymir_triage_in_progress and verify the trigger's author via the Jira changelog. A new cron job is introduced to sweep for these requests, and GitLab authentication is updated to support custom fork namespaces. The review feedback correctly identifies a high-severity issue in the triage agent where failing to write the in-progress label re-queues the task without incrementing its attempt count, which could cause an infinite loop and block the queue; a suggestion is provided to use the retry helper instead.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[majamassarini]

/gemini review

[gemini-code-assist]

Code Review

This pull request replaces the global SILENT_RUN configuration with a per-issue user_triggered flag, enabling a silent-by-default behavior unless explicitly triggered by a Red Hat Employee via the new ymir_todo label. The Jira Issue Fetcher has been updated to verify the label's author through the issue's changelog and atomically swap trigger labels for ymir_triage_in_progress before enqueuing. Additionally, a new cron job has been introduced to sweep for these requests promptly. The review feedback highlights two critical issues: first, a potential infinite retry loop in the fetcher if the author verification fails with a permanent HTTP error (such as a 404 or 403); second, an unhandled exception in the triage agent's error-handling path that could crash the agent if writing the terminal error label fails.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[TomasTomecek]

Very nice work Maja, opus is very happy with your PR :)

Overall the PR is solid — the dedup logic is carefully designed
and the critical-write retry is a good addition. The ack-after-retry bug is the only clear correctness issue.

[lbarcziova]

great job! 🚀