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> }}

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions