alex/.profile
Watch
1
0
Fork
You've already forked .profile
 0
Code Issues 1 Pull requests Projects 1 Activity Actions

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

Merged
alex merged 1 commit from pi/issue11-1783865730356 into master 2026-07-12 14:18:59 +00:00
Conversation 0 Commits 1 Files changed 2 +10 -3
pi commented 2026-07-12 14:15:31 +00:00
Contributor
Copy link

Problem

The if condition in pi-assign.yml (line 22) causes the job to be skipped when triggered via workflow_call from other repos:

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

When another repo (e.g. alex/ansible) calls this reusable workflow via workflow_call, the forgejo.event context represents the workflow_call event — not the original issues: assigned event. The workflow_call event payload has no assignee field, so forgejo.event.assignee.login is null, the condition evaluates to false, and the job is skipped.

This is exactly what happened with ansible#67 — the issue was assigned to Pi, the wrapper workflow fired, called this reusable workflow, but the job was skipped (run 160).

Fix

Add forgejo.event_name == 'workflow_call' as an alternative condition to both pi-assign.yml and pi.yml:

# pi-assign.yml
if: forgejo.event_name == 'workflow_call' || forgejo.event.assignee.login == 'pi'

# pi.yml
if: |
  forgejo.event_name == 'workflow_call'
  || (startsWith(forgejo.event.comment.body, '/pi ') && ...)
  || (startsWith(forgejo.event.review.content, '/pi ') && ...)

When called via workflow_call, the caller repo is the one that receives the original event and is responsible for filtering. The reusable workflow should run unconditionally when invoked this way.

Note for caller repos

Caller repos (e.g. ansible) should add their own if filter on the calling job so they don't waste runs on non-Pi assignments:

jobs:
  call-pi:
    if: forgejo.event.assignee.login == 'pi'
    uses: alex/.profile/.forgejo/workflows/pi-assign.yml@master
    secrets: inherit

Fixes #11

## Problem The `if` condition in `pi-assign.yml` (line 22) causes the job to be **skipped** when triggered via `workflow_call` from other repos: ```yaml if: forgejo.event.assignee.login == 'pi' ``` When another repo (e.g. `alex/ansible`) calls this reusable workflow via `workflow_call`, the `forgejo.event` context represents the `workflow_call` event — **not** the original `issues: assigned` event. The `workflow_call` event payload has no `assignee` field, so `forgejo.event.assignee.login` is `null`, the condition evaluates to `false`, and the job is skipped. This is exactly what happened with [ansible#67](https://forge.l3x.in/alex/ansible/issues/67) — the issue was assigned to Pi, the wrapper workflow fired, called this reusable workflow, but the job was skipped ([run 160](https://forge.l3x.in/alex/ansible/actions/runs/160)). ## Fix Add `forgejo.event_name == 'workflow_call'` as an alternative condition to both `pi-assign.yml` and `pi.yml`: ```yaml # pi-assign.yml if: forgejo.event_name == 'workflow_call' || forgejo.event.assignee.login == 'pi' ``` ```yaml # pi.yml if: | forgejo.event_name == 'workflow_call' || (startsWith(forgejo.event.comment.body, '/pi ') && ...) || (startsWith(forgejo.event.review.content, '/pi ') && ...) ``` When called via `workflow_call`, the caller repo is the one that receives the original event and is responsible for filtering. The reusable workflow should run unconditionally when invoked this way. ## Note for caller repos Caller repos (e.g. `ansible`) should add their own `if` filter on the calling job so they don't waste runs on non-Pi assignments: ```yaml jobs: call-pi: if: forgejo.event.assignee.login == 'pi' uses: alex/.profile/.forgejo/workflows/pi-assign.yml@master secrets: inherit ``` Fixes #11
Co-authored-by: alex <alex@forge.l3x.in>
alex merged commit fd4d3cf489 into master 2026-07-12 14:18:59 +00:00
alex deleted branch pi/issue11-1783865730356 2026-07-12 14:18:59 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
dependencies
Renovate stuff

No labels
dependencies
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
alex/.profile!12
No description provided.