Job assign filtering seems to fail

alex commented

2026-07-12 14:12:44 +00:00

Owner

if: forgejo.event.assignee.login == 'pi'

This event was supposed to triggger a Pi session but didn't: alex/ansible#67 (assigned to Pi) -> https://forge.l3x.in/alex/ansible/actions/runs/160/jobs/0/attempt/1 (skipped)

https://forge.l3x.in/alex/.profile/src/commit/4e3864b711959ecbe41d4dc8f5cbf3f0c6522064/.forgejo/workflows/pi-assign.yml#L22 This event was supposed to triggger a Pi session but didn't: https://forge.l3x.in/alex/ansible/issues/67 (assigned to Pi) -> https://forge.l3x.in/alex/ansible/actions/runs/160/jobs/0/attempt/1 (skipped)

alex commented

2026-07-12 14:12:51 +00:00

Author

Owner

/pi analyze and report

pi referenced this issue from a pull request that will close it,

2026-07-12 14:15:31 +00:00

fix(ci): allow workflow_call triggers to pass through if-guard in Pi workflows #12

pi commented

2026-07-12 14:15:40 +00:00

Contributor

Let me investigate the referenced ansible repo's workflow and check the job logs.Now let me check if there's a local copy of the ansible repo's workflow or any other referencing files:Now I have a complete picture. Let me verify my hypothesis about the workflow_call event context by checking the Forgejo Actions documentation behavior:## Analysis

I've identified the root cause. Here's the breakdown:

Root Cause: `workflow_call` event context doesn't carry the caller's event payload

The if condition on line 22 of pi-assign.yml is:

if: forgejo.event.assignee.login == 'pi'

This works fine for direct triggers in the .profile repo (where forgejo.event_name is issues or pull_request and the event payload contains an assignee object).

However, when other repos (like alex/ansible) call this workflow via workflow_call, the forgejo.event context represents the workflow_call event itself — not the original issues: assigned event from the caller. The workflow_call event payload looks like:

{ "inputs": {} }

There is no assignee field. So forgejo.event.assignee.login evaluates to null, the condition null == 'pi' is false, and the job is skipped.

What happened with ansible#67

Issue #67 was assigned to pi → triggered ansible's wrapper workflow on issues: [assigned]
Ansible's wrapper called alex/.profile/.forgejo/workflows/pi-assign.yml@master via workflow_call
In the reusable workflow, forgejo.event.assignee was null (event was workflow_call, not issues)
if evaluated to false → job skipped → Pi never ran

The fix

The if guard must allow workflow_call triggers to pass through, since the caller repo is the one that actually receives the assignment event and should be responsible for filtering:The same latent bug exists in pi.yml (the comment-triggered workflow). When called via workflow_call, forgejo.event.comment and forgejo.event.review won't exist either:Let me verify both files look correct:Both files look correct. Now let me create a PR with these changes:## Summary

Root cause: The if guard in pi-assign.yml checks forgejo.event.assignee.login == 'pi', but when other repos call the workflow via workflow_call, the event context contains a workflow_call payload (just { "inputs": {} }) — not the original issues: assigned event. There's no assignee field, so the condition is always false and the job gets skipped.

Fix applied (PR #12): Added forgejo.event_name == 'workflow_call' as an alternative pass-through condition in both pi-assign.yml and pi.yml. When invoked via workflow_call, the caller repo is responsible for filtering (it's the one that receives the assignment event). The same latent bug existed in pi.yml (comment-triggered), so both were fixed.

Recommendation for caller repos (e.g. ansible): Add an if: forgejo.event.assignee.login == 'pi' guard on the calling job in the wrapper workflow, so it only invokes the reusable workflow for Pi assignments.

Let me investigate the referenced ansible repo's workflow and check the job logs.Now let me check if there's a local copy of the ansible repo's workflow or any other referencing files:Now I have a complete picture. Let me verify my hypothesis about the `workflow_call` event context by checking the Forgejo Actions documentation behavior:## Analysis I've identified the root cause. Here's the breakdown: ### Root Cause: `workflow_call` event context doesn't carry the caller's event payload The `if` condition on line 22 of `pi-assign.yml` is: ```yaml if: forgejo.event.assignee.login == 'pi' ``` This works fine for **direct triggers** in the `.profile` repo (where `forgejo.event_name` is `issues` or `pull_request` and the event payload contains an `assignee` object). However, when **other repos** (like `alex/ansible`) call this workflow via `workflow_call`, the `forgejo.event` context represents the `workflow_call` event itself — **not** the original `issues: assigned` event from the caller. The `workflow_call` event payload looks like: ```json { "inputs": {} } ``` There is **no `assignee` field**. So `forgejo.event.assignee.login` evaluates to `null`, the condition `null == 'pi'` is `false`, and the job is **skipped**. ### What happened with ansible#67 1. Issue #67 was assigned to `pi` → triggered ansible's wrapper workflow on `issues: [assigned]` 2. Ansible's wrapper called `alex/.profile/.forgejo/workflows/pi-assign.yml@master` via `workflow_call` 3. In the reusable workflow, `forgejo.event.assignee` was `null` (event was `workflow_call`, not `issues`) 4. `if` evaluated to `false` → **job skipped** → Pi never ran ### The fix The `if` guard must allow `workflow_call` triggers to pass through, since the caller repo is the one that actually receives the assignment event and should be responsible for filtering:The same latent bug exists in `pi.yml` (the comment-triggered workflow). When called via `workflow_call`, `forgejo.event.comment` and `forgejo.event.review` won't exist either:Let me verify both files look correct:Both files look correct. Now let me create a PR with these changes:## Summary **Root cause:** The `if` guard in `pi-assign.yml` checks `forgejo.event.assignee.login == 'pi'`, but when other repos call the workflow via `workflow_call`, the event context contains a `workflow_call` payload (just `{ "inputs": {} }`) — **not** the original `issues: assigned` event. There's no `assignee` field, so the condition is always `false` and the job gets skipped. **Fix applied** (PR #12): Added `forgejo.event_name == 'workflow_call'` as an alternative pass-through condition in both `pi-assign.yml` and `pi.yml`. When invoked via `workflow_call`, the caller repo is responsible for filtering (it's the one that receives the assignment event). The same latent bug existed in `pi.yml` (comment-triggered), so both were fixed. **Recommendation for caller repos** (e.g. `ansible`): Add an `if: forgejo.event.assignee.login == 'pi'` guard on the calling job in the wrapper workflow, so it only invokes the reusable workflow for Pi assignments. --- [View action run](https://forge.l3x.in/alex/.profile/actions/runs/12) | Model: zai/glm-5.2 (thinking: xhigh) | Time: 2m 49s | Tokens: 98.5K | Pi SDK v0.80.3 | Action v2.25.1-develop (develop @ 1027378)

alex closed this issue

2026-07-12 14:18:59 +00:00

Rows
Columns

Job assign filtering seems to fail #11

Root Cause: workflow_call event context doesn't carry the caller's event payload

What happened with ansible#67

The fix

Root Cause: `workflow_call` event context doesn't carry the caller's event payload