Enable ymir todo trigger

Makefile

@@ -3,9 +3,9 @@ COMPOSE_FILE ?= compose.yaml
 DRY_RUN ?= false
 MOCK_JIRA ?= false
 JIRA_DRY_RUN ?= false
+JIRA_ALLOW_STATUS_CHANGES ?= false
 AUTO_CHAIN ?= true
 FORCE_CVE_TRIAGE ?= false
-SILENT_RUN ?= false
 RUN_LLM_JUDGE ?= true
 
 COMPOSE ?= $(shell if podman compose ls >/dev/null 2>&1; then echo "podman compose"; elif command -v podman-compose >/dev/null 2>&1; then echo "podman-compose"; else echo "docker-compose"; fi)
@@ -44,7 +44,6 @@ run-triage-agent-standalone:
 		-e MOCK_JIRA=$(MOCK_JIRA) \
 		-e JIRA_DRY_RUN=$(JIRA_DRY_RUN) \
 		-e FORCE_CVE_TRIAGE=$(FORCE_CVE_TRIAGE) \
-		-e SILENT_RUN=$(SILENT_RUN) \
 		triage-agent
 
 .PHONY: run-triage-agent-e2e-tests
@@ -202,11 +201,11 @@ build-jira-issue-fetcher:
 
 .PHONY: start
 start:
-	DRY_RUN=$(DRY_RUN) MOCK_JIRA=$(MOCK_JIRA) JIRA_DRY_RUN=$(JIRA_DRY_RUN) AUTO_CHAIN=$(AUTO_CHAIN) SILENT_RUN=$(SILENT_RUN) $(COMPOSE_AGENTS) up
+	DRY_RUN=$(DRY_RUN) MOCK_JIRA=$(MOCK_JIRA) JIRA_DRY_RUN=$(JIRA_DRY_RUN) JIRA_ALLOW_STATUS_CHANGES=$(JIRA_ALLOW_STATUS_CHANGES) AUTO_CHAIN=$(AUTO_CHAIN) $(COMPOSE_AGENTS) up
 
 .PHONY: start-detached
 start-detached:
-	DRY_RUN=$(DRY_RUN) MOCK_JIRA=$(MOCK_JIRA) JIRA_DRY_RUN=$(JIRA_DRY_RUN) AUTO_CHAIN=$(AUTO_CHAIN) SILENT_RUN=$(SILENT_RUN) $(COMPOSE_AGENTS) up -d
+	DRY_RUN=$(DRY_RUN) MOCK_JIRA=$(MOCK_JIRA) JIRA_DRY_RUN=$(JIRA_DRY_RUN) JIRA_ALLOW_STATUS_CHANGES=$(JIRA_ALLOW_STATUS_CHANGES) AUTO_CHAIN=$(AUTO_CHAIN) $(COMPOSE_AGENTS) up -d
 
 .PHONY: stop
 stop:

README-agents.md

@@ -22,6 +22,27 @@ Three agents process tasks through Redis queues:
 
 **Always** use `DRY_RUN=true` if you are developing locally or just wanna give the agents a try.
 
+## Jira status changes (opt-in)
+
+By default, agents do NOT change the Jira workflow status of issues
+(e.g. "New" → "In Progress" when the backport agent picks up a task,
+or "Release Pending" / "Closed" when the issue-verification agent
+finishes), and the preliminary-testing agent does NOT set the
+`Preliminary Testing` field to `Pass`. The Pass field is gated by the
+same flag because setting it admits the build into the next compose,
+triggers erratum creation, and moves the issue to Integration — its
+downstream effect is equivalent to a status transition. To enable all
+of the above, set:
+
+```bash
+JIRA_ALLOW_STATUS_CHANGES=true
+```
+
+When unset or `false`, status-change calls and the prelim-testing Pass
+write are short-circuited and a log line records what *would* have
+happened.
+`DRY_RUN=true` also suppresses these writes independently of this flag.
+
 ## Jira mocking
 
 If you clone testing Jira files from

agents_as_skills/triage/SKILL.md

@@ -13,9 +13,6 @@ arguments:
   - name: force_cve_triage
     description: "If true, force triage of CVE issues that would normally be deferred or rejected (eligibility=PENDING_DEPENDENCIES or NEVER). Default: false"
     required: false
-  - name: silent_run
-    description: "If true, only update JIRA for not-affected and postponed resolutions. Default: false"
-    required: false
 ---
 
 # Triage Skill
@@ -30,7 +27,6 @@ You are a Red Hat Enterprise Linux developer tasked to analyze Jira issues for R
 - `dry_run`: {{dry_run}}
 - `auto_chain`: {{auto_chain}}
 - `force_cve_triage`: {{force_cve_triage}}
-- `silent_run`: {{silent_run}}
 
 ## Tools
 
@@ -701,10 +697,7 @@ Proceed to **Step 7**.
 
 If `dry_run` is true, end the workflow and output the `triage_result`.
 
-Check whether JIRA should be updated based on `silent_run`:
-- If `silent_run` is false: always update JIRA.
-- If `silent_run` is true: only update JIRA if `triage_result.resolution` is `"not-affected"` or `"postponed"`.
-- If JIRA should not be updated, end the workflow and output the `triage_result`.
+Default is silent: only post a JIRA comment when `triage_result.resolution` is `"not-affected"` or `"postponed"` (resolutions that have no MR artifact, so the comment is the only visible explanation). For all other resolutions, end the workflow and output the `triage_result` without commenting.
 
 Format the JIRA comment based on the resolution type:
 

compose.yaml

@@ -9,8 +9,8 @@ x-beeai-env: &beeai-env
   MAX_RETRIES: 3
   DRY_RUN: ${DRY_RUN:-false}
   JIRA_DRY_RUN: ${JIRA_DRY_RUN:-false}
+  JIRA_ALLOW_STATUS_CHANGES: ${JIRA_ALLOW_STATUS_CHANGES:-false}
   AUTO_CHAIN: ${AUTO_CHAIN:-true}
-  SILENT_RUN: ${SILENT_RUN:-false}
   REQUESTS_CA_BUNDLE: /etc/pki/tls/certs/ca-bundle.crt
 
 # Base template for BeeAI agents

jira_label_workflow_routing.md

@@ -30,7 +30,7 @@ stateDiagram-v2
 flowchart TD
     FETCH[Jira Issue Fetcher]
 
-    FETCH -->|No Ymir labels<br/>OR ymir_retry_needed| TRIAGE[triage_queue]
+    FETCH -->|No Ymir labels<br/>OR ymir_retry_needed<br/>OR ymir_todo added by RH-Employee| TRIAGE[triage_queue]
 
     TRIAGE --> TRIAGE_AGENT[Triage Agent]
 
@@ -93,12 +93,13 @@ flowchart TD
 | `ymir_retry_needed` | Trigger retry | Forces reprocessing |
 | `ymir_triaged` | Triage completed, no automated follow-up | Terminal state |
 | `ymir_fusa` | Functional Safety | Requires maintainer review |
+| `ymir_todo` | Maintainer-facing trigger for an e2e run | Fetcher swaps it for `ymir_triage_in_progress` on enqueue; only honored when the changelog shows the label was added by a member of the `Red Hat Employee` Jira group (verified per-issue, not via JQL). The triage run posts an ack comment and a result comment so the requester gets feedback. Default is silent — without `ymir_todo`, no comments are posted. |
 
 ## Queue Types Summary
 
 | Queue | Type | Triggers | Labels Added | Status |
 |-------|------|----------|--------------|--------|
-| `triage_queue` | Input | No labels OR retry_needed | - | Active |
+| `triage_queue` | Input | No labels OR `ymir_retry_needed` OR `ymir_todo` | `ymir_triage_in_progress` (set by fetcher atomic flip for retry/todo, or by agent at triage start for fresh issues) | Active |
 | `rebase_queue_c9s` | Input | Resolution=REBASE, RHEL 8/9 | `ymir_triaged_rebase` | Active (AUTO_CHAIN only) |
 | `rebase_queue_c10s` | Input | Resolution=REBASE, RHEL 10+ | `ymir_triaged_rebase` | Active (AUTO_CHAIN only) |
 | `backport_queue_c9s` | Input | Resolution=BACKPORT, RHEL 8/9 | `ymir_triaged_backport` | Active (AUTO_CHAIN only) |
@@ -113,28 +114,60 @@ flowchart TD
 
 ## Deduplication Logic
 
-**Note:** The Jira Issue Fetcher only decides whether to queue an issue for processing based on labels. The actual label cleanup (including removal of `ymir_retry_needed`) happens in the Triage Agent after it consumes the task from the queue.
+**Trigger labels are consumed by the fetcher, all other labels by the agent.** The fetcher atomically removes `ymir_todo` and `ymir_retry_needed` before pushing to Redis, replacing them with `ymir_triage_in_progress` so the very next sweep sees the in-progress marker and skips. Every other `ymir_*` label is cleaned up by the triage agent when it pops the task. If the fetcher's atomic flip fails after retries, the Redis push is **skipped** — the issue stays eligible for the next sweep with its trigger label intact, rather than being enqueued without a dedup anchor.
 
 ```mermaid
 flowchart TD
     START[Jira Issue Fetcher<br/>Found issue]
-    CHECK{Has any<br/>ymir_* label?}
+    INPROG{Has any<br/>ymir_*_in_progress?}
+    TODO{Has ymir_todo?<br/>added by a member of<br/>Red Hat Employee group}
     RETRY{Has<br/>ymir_retry_needed?}
+    OTHER{Has any other<br/>ymir_* label?}
+
+    START --> INPROG
+    INPROG -->|Yes| SKIP_RUN[Skip — already running]
+    INPROG -->|No| TODO
+    TODO -->|Yes| FLIP_TODO[Atomic flip:<br/>+ymir_triage_in_progress<br/>-ymir_todo]
+    TODO -->|No| RETRY
+    RETRY -->|Yes| FLIP_RETRY[Atomic flip:<br/>+ymir_triage_in_progress<br/>-ymir_retry_needed]
+    RETRY -->|No| OTHER
+    OTHER -->|Yes| SKIP_DONE[Skip — already processed]
+    OTHER -->|No| PUSH_FRESH[Push to triage_queue<br/>user_triggered=False]
+
+    FLIP_TODO --> PUSH_USER[Push to triage_queue<br/>user_triggered=True]
+    FLIP_RETRY --> PUSH_RETRY[Push to triage_queue<br/>user_triggered=False]
+
+    style PUSH_FRESH fill:#c8e6c9
+    style PUSH_USER fill:#c8e6c9
+    style PUSH_RETRY fill:#c8e6c9
+    style SKIP_RUN fill:#ffcdd2
+    style SKIP_DONE fill:#ffcdd2
+```
 
-    START --> CHECK
-    CHECK -->|No| ADD[Add to triage_queue]
-    CHECK -->|Yes| RETRY
-    RETRY -->|Yes| ADD
-    RETRY -->|No| SKIP[Skip - already processed]
+## Run Behaviour by Trigger and Flag
 
-    ADD --> TRIAGE_PROCESS[Triage Agent processes issue]
-    TRIAGE_PROCESS --> CLEANUP[Triage Agent removes<br/>all ymir_* labels]
+Two env-var flags affect pipeline behaviour: `DRY_RUN` and `JIRA_ALLOW_STATUS_CHANGES`. Verbosity is no longer controlled by an env var — the system is silent by default. The only way to opt into comments is per-issue, by adding `ymir_todo` (which flows through the task as `user_triggered=True`).
 
-    style ADD fill:#c8e6c9
-    style SKIP fill:#ffcdd2
-    style CLEANUP fill:#e1f5fe
-```
+Ground rules:
+
+- **Default is silent.** No result or error comments are posted on the Jira issue, and intermediate `_failed` labels are not written. Only `not-affected`, `postponed`, `open-ended-analysis`, and `clarification-needed` triage resolutions still post a comment unbidden (those have no MR to look at, so the comment is the only visible explanation).
+- **`user_triggered=True`** (set on the task when the issue carried `ymir_todo`) **bypasses every silence filter.** The triage agent posts an immediate private ack comment, posts the result comment, and writes `_failed` labels normally.
+- **Labels that are state, not notification, are always written.** `ymir_triage_in_progress` at the start of triage, terminal `ymir_*_errored` / `ymir_triaged_*` at the end. Suppressing them would break dedup against the next fetcher sweep.
+- **Jira workflow status changes are opt-in via `JIRA_ALLOW_STATUS_CHANGES`.** When the env var is unset or `false` (the default), the rebase/backport agents do NOT move the issue to "In Progress" on task pop, and the issue-verification agent does NOT transition issues to "Release Pending" / "Closed". When set to `true`, all of those transitions happen. The same flag also gates the preliminary-testing agent setting **`Preliminary Testing = Pass`** — that field admits the build into the next compose, triggers erratum creation, and moves the issue to Integration. Triage and the fetcher never touch the workflow status, regardless of the flag.
+- **`DRY_RUN` is read by both fetcher and agent.** On the fetcher, `DRY_RUN=true` skips the atomic Jira label flip (`ymir_todo` / `ymir_retry_needed` are NOT consumed; `ymir_triage_in_progress` is NOT stamped) but the task is still pushed to Redis with the correct `user_triggered` value, so the agent — also presumably in `DRY_RUN` — can exercise its full dry-mode flow. Implication: the trigger label stays on the issue, so every subsequent fetcher sweep re-picks the same issue. That is fine in a test environment; never run a production cron with `DRY_RUN=true`. `DRY_RUN=true` also implies status changes are skipped, independent of `JIRA_ALLOW_STATUS_CHANGES`.
+
+What happens for each trigger state:
+
+| Trigger state at sweep time | Default behaviour | `DRY_RUN=true` |
+|---|---|---|
+| **No `ymir_*` labels** (fresh issue) | Fetcher pushes to `triage_queue`. Agent stamps `ymir_triage_in_progress`, runs triage, writes a terminal `ymir_*` label. Result comment is suppressed unless the resolution is `not-affected`, `postponed`, `open-ended-analysis`, or `clarification-needed`. If the run auto-chains to rebase or backport, the downstream agent moves the Jira workflow status to "In Progress" when it pops the task — **only if `JIRA_ALLOW_STATUS_CHANGES=true`**; otherwise the status is left untouched. | Agent runs triage but `set_jira_labels` / `add_jira_comment` short-circuit on `DRY_RUN`. No labels, no comment, no MR, no workflow status change. Issue untouched in Jira. |
+| **`ymir_todo`** (added by a member of `Red Hat Employee`, no `_in_progress`) | Fetcher verifies the latest `ymir_todo` add in the issue's changelog was performed by a Red Hat Employee; if so, atomically flips `ymir_todo` → `ymir_triage_in_progress` and pushes with `user_triggered=True`. Agent posts a private ack comment and a result comment on completion. `_failed` labels are written normally. Workflow status change is the same as the fresh-issue path (set by rebase/backport on auto-chain, gated on `JIRA_ALLOW_STATUS_CHANGES`). | Fetcher still verifies the author and skips the atomic flip (`ymir_todo` stays on the issue), but still pushes to Redis with `user_triggered=True`. Agent runs in dry mode and writes nothing; workflow status not changed. **Subsequent fetcher sweeps will re-push the same issue** because the trigger label was never consumed. |
+| **`ymir_retry_needed`** (no `_in_progress`) | Fetcher atomically flips `ymir_retry_needed` → `ymir_triage_in_progress`, pushes with `user_triggered=False`. Agent runs full triage; behaves exactly like a fresh-issue run (no ack comment, result comment only for the four "no-MR" resolutions). Workflow status change is the same as the fresh-issue path (gated on `JIRA_ALLOW_STATUS_CHANGES`). | Fetcher skips the atomic flip (`ymir_retry_needed` stays on the issue) but still pushes to Redis with `user_triggered=False`. Agent runs in dry mode and writes nothing; workflow status not changed. Subsequent fetcher sweeps will re-push the same issue. |
+| **`ymir_todo`** or **`ymir_retry_needed`** **+** any `ymir_*_in_progress` label | Fetcher skips. Not enqueued. Workflow status not affected. | Fetcher skips. Not enqueued. Workflow status not affected. |
+| **Any other terminal `ymir_*` label** (e.g. `ymir_triaged_rebase`, `ymir_rebased`, `ymir_triage_errored`) | Fetcher skips. Re-run by adding `ymir_todo` (recommended — produces an ack + result comment) or `ymir_retry_needed`. Workflow status not affected. | Fetcher skips. Workflow status not affected. |
+
+JQL no longer restricts `ymir_todo` by assignee — the fetcher instead verifies per-issue that the user who added the label belongs to the `Red Hat Employee` Jira group by walking the issue's changelog. If the latest `ymir_todo` add was performed by an external collaborator (or the author cannot be verified), the fetcher skips the issue with a warning and does not flip the label.
 
 ---
 
-**Last Updated:** 2026-03-03
+**Last Updated:** 2026-06-04

openshift/Makefile

@@ -5,4 +5,8 @@ run-jira-issue-fetcher:
 	oc delete job jira-issue-fetcher-manual || true
 	oc create job jira-issue-fetcher-manual --from=cronjob/jira-issue-fetcher
 
-.PHONY: deploy run-jira-issue-fetcher
+run-jira-issue-fetcher-todo:
+	oc delete job jira-issue-fetcher-todo-manual || true
+	oc create job jira-issue-fetcher-todo-manual --from=cronjob/jira-issue-fetcher-todo
+
+.PHONY: deploy run-jira-issue-fetcher run-jira-issue-fetcher-todo

openshift/README.md

@@ -102,10 +102,33 @@ Agents are deployed in the `jotnar-ymir--jotnar-ymir` project.
 
 ## Jira Issue Fetcher Deployment
 
-Manually run jira issue fetcher:
+Two CronJobs run the fetcher with different JQL queries:
+
+| CronJob | Schedule | QUERY | ConfigMap |
+|---|---|---|---|
+| `jira-issue-fetcher` | `*/30 * * * *` | A generic filter for processing a batch of issues (e.g. early adopters) — currently `filter = "Ymir early adopters CVEs"` | `jira-issue-fetcher-filter-env` |
+| `jira-issue-fetcher-todo` | `*/5 * * * *` | `labels = "ymir_todo"` | `jira-issue-fetcher-todo-env` |
+
+Both share the common knobs (`IGNORED_COMPONENTS`, `MAX_ISSUES`, `LOGLEVEL`) from `jira-issue-fetcher-env`. Each pod mounts the shared configmap plus its per-cron QUERY configmap. To target a different batch, edit `configmap-jira-issue-fetcher-filter-env.yml` and re-apply.
+
+Manually run either fetcher:
+
+```bash
+make run-jira-issue-fetcher       # generic batch filter
+make run-jira-issue-fetcher-todo  # ymir_todo sweep
+```
+
+## Agent runtime knobs (`agents-env` ConfigMap)
+
+| Key | Default | Effect |
+|---|---|---|
+| `JIRA_ALLOW_STATUS_CHANGES` | `"false"` | When `"false"`, agents do NOT change Jira issue statuses (no "New" → "In Progress" on rebase/backport start, no "Release Pending" / "Closed" on verification finish) and the preliminary-testing agent does NOT set `Preliminary Testing = Pass` (that field admits the build into a compose, triggers erratum creation, and moves the issue to Integration). Flip to `"true"` to allow all of the above. `DRY_RUN=true` further short-circuits these writes independently. |
+
+To enable production status transitions:
 
 ```bash
-make run-jira-issue-fetcher
+oc patch configmap agents-env --type merge -p '{"data":{"JIRA_ALLOW_STATUS_CHANGES":"true"}}'
+oc rollout restart deployment -l app=triage-agent  # plus any other agent deployments
 ```
 
 ## Triggering the Pipeline Manually

openshift/configmap-agents-env.yml

@@ -1,6 +1,5 @@
 apiVersion: v1
 data:
-  SILENT_RUN: "true"
   MAX_RETRIES: "3"
   GIT_REPO_BASEPATH: /git-repos
   # The maximum number of retries for a single step in the agent execution.
@@ -11,6 +10,12 @@ data:
   # This was increased from 140 to handle complex rebases and backports.
   BEEAI_MAX_ITERATIONS: "255"
   REASONING_EFFORT: high
+  # When "false" (default), agents do NOT change Jira issue statuses
+  # (e.g. New -> In Progress on rebase/backport start, Release Pending on
+  # verification close). Set to "true" to allow status transitions. The
+  # status-change comment produced by issue-verification is suppressed
+  # alongside the transition.
+  JIRA_ALLOW_STATUS_CHANGES: "false"
 immutable: false
 kind: ConfigMap
 metadata:

openshift/configmap-jira-issue-fetcher-env.yml

@@ -1,6 +1,5 @@
 apiVersion: v1
 data:
-  QUERY: 'filter = "Ymir early adopters CVEs"'
   IGNORED_COMPONENTS: "firefox,thunderbird,firefox-flatpak-container,thunderbird-flatpak-container,webkit2gtk3,openjdk,postfix"
   MAX_ISSUES: "20"
   LOGLEVEL: "INFO"

openshift/configmap-jira-issue-fetcher-filter-env.yml

@@ -0,0 +1,7 @@
+apiVersion: v1
+data:
+  QUERY: 'filter = "Ymir early adopters CVEs"'
+immutable: false
+kind: ConfigMap
+metadata:
+  name: jira-issue-fetcher-filter-env

openshift/configmap-jira-issue-fetcher-todo-env.yml

@@ -0,0 +1,7 @@
+apiVersion: v1
+data:
+  QUERY: 'labels = "ymir_todo"'
+immutable: false
+kind: ConfigMap
+metadata:
+  name: jira-issue-fetcher-todo-env

openshift/cronjob-jira-issue-fetcher-todo.yml

@@ -0,0 +1,62 @@
+apiVersion: batch/v1
+kind: CronJob
+metadata:
+  name: jira-issue-fetcher-todo
+  labels:
+    app: jira-issue-fetcher-todo
+    component: scheduler
+spec:
+  schedule: "*/5 * * * *"  # Every 5 minutes — picks up ymir_todo maintainer requests promptly
+  concurrencyPolicy: Forbid  # Prevent overlapping runs
+  successfulJobsHistoryLimit: 3
+  failedJobsHistoryLimit: 5
+  suspend: true
+  jobTemplate:
+    metadata:
+      labels:
+        app: jira-issue-fetcher-todo
+        component: job
+    spec:
+      backoffLimit: 2
+      activeDeadlineSeconds: 240  # 4 minutes max runtime (cron is */5, must not overlap)
+      template:
+        metadata:
+          labels:
+            app: jira-issue-fetcher-todo
+            component: pod
+        spec:
+          restartPolicy: Never
+          containers:
+          - name: jira-issue-fetcher-env
+            image: 'jira-issue-fetcher:prod'
+            imagePullPolicy: Always
+            envFrom:
+            - configMapRef:
+                name: endpoints-env
+            - configMapRef:
+                name: jira-env
+            - secretRef:
+                name: jira-env
+            - configMapRef:
+                name: jira-issue-fetcher-env
+            - configMapRef:
+                name: jira-issue-fetcher-todo-env
+            resources:
+              limits:
+                cpu: "200m"
+                memory: "128Mi"
+            securityContext:
+              allowPrivilegeEscalation: false
+              runAsNonRoot: true
+              seccompProfile:
+                type: RuntimeDefault
+              capabilities:
+                drop:
+                - ALL
+          securityContext:
+            runAsNonRoot: true
+            seccompProfile:
+              type: RuntimeDefault
+          dnsPolicy: ClusterFirst
+          schedulerName: default-scheduler
+          terminationGracePeriodSeconds: 30