Skip to content

Custom frontmatter if: replaces the label_command-derived condition instead of combining with it #47594

Description

@ludoviclafole

Description

When a workflow uses a label_command trigger together with a custom top-level if: in the frontmatter, the compiled lock's activation gate contains only the custom condition — the label-name condition derived from label_command is silently dropped. The workflow then activates on any label event (subject only to the custom if:), which defeats the purpose of the trigger and re-introduces agent-run costs for unrelated labels.

Repro (gh-aw v0.82.14)

---
on:
  label_command:
    name: "state:approved"
engine: copilot
if: ${{ github.event.issue.state == 'open' }}
safe-outputs:
  add-comment:
---

Without the custom if:, the compiled activation job condition is:

needs.pre_activation.outputs.activated == 'true' && (github.event_name == 'issues' && github.event.label.name == 'state:approved' || ...)

With the custom if:, it becomes:

needs.pre_activation.outputs.activated == 'true' && (github.event.issue.state == 'open')

The github.event.label.name check only survives in the concurrency group key, which does not filter anything.

Expected

The custom if: should be AND-combined with the trigger-derived condition:

activated && (label conditions) && (custom if)

Workaround

Manually repeat the label condition inside the custom if::

if: ${{ github.event.label.name == 'state:approved' && <condition> }}

Metadata

Metadata

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions