Skip to content

feat: add bidirectionalLabelMatch option and deprecate exactMatch#5031

Open
Brend-Smits wants to merge 3 commits intomainfrom
fix/exact-match-was-not-really-exact-but-partial-exact
Open

feat: add bidirectionalLabelMatch option and deprecate exactMatch#5031
Brend-Smits wants to merge 3 commits intomainfrom
fix/exact-match-was-not-really-exact-but-partial-exact

Conversation

@Brend-Smits
Copy link
Contributor

@Brend-Smits Brend-Smits commented Feb 13, 2026

Summary

Introduce a new bidirectionalLabelMatch option that performs strict two-way label matching (runner labels must equal workflow labels as a set). This preserves the existing exactMatch behavior (unidirectional subset check) to avoid breaking changes.

Problem

The bidirectionalLabelMatch option for runner label matching requires labels to be identical in both directions. Previously, a runner with labels [A, B, C, D] would match a job requesting [A, B, C] when exactMatch was true. Now, bidirectionalLabelMatch=true requires the labels to be exactly identical — the runner will only match if the job requests exactly [A, B, C, D].

This change affects users who have runners with extra labels (e.g., on-demand) that were previously matching jobs not explicitly requesting those labels. After this change, such runners will only be used when jobs explicitly request all of the runner's labels.

Before: Job [A,B,C] + Runner [A,B,C,D] + exactMatch=true       → Match
After:  Job [A,B,C] + Runner [A,B,C,D] + bidirectionalLabelMatch=true → No Match

exactMatch was supposed to have this behavior, but to avoid breaking changes, the variable will be deprecated to give users time to migrate.

Changes

  • Add bidirectionalLabelMatch to MatcherConfig interface (optional, defaults to false)
  • Update canRunJob to support bidirectional matching when enabled
  • Deprecate exactMatch in Terraform variables with migration guidance
  • Add bidirectionalLabelMatch to multi-runner and webhook variable types
  • Add new root variable enable_runner_bidirectional_label_match
  • Add comprehensive test coverage for bidirectional matching

Migration

To migrate, use bidirectionalLabelMatch instead of exactMatch in your runner configs. Then either:

  1. Remove extra labels from runner configurations, or
  2. Add the extra labels to your workflow job runs-on

Co-authored-by: Stuart Pearson stuart.pearson@philips.com

@Brend-Smits Brend-Smits requested a review from a team as a code owner February 13, 2026 14:41
@github-actions
Copy link
Contributor

github-actions bot commented Feb 13, 2026

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

@Brend-Smits Brend-Smits force-pushed the fix/exact-match-was-not-really-exact-but-partial-exact branch from 34b7069 to f597650 Compare February 13, 2026 14:44
@Brend-Smits Brend-Smits force-pushed the fix/exact-match-was-not-really-exact-but-partial-exact branch from f86dfa0 to 7a14043 Compare March 9, 2026 09:33
@Brend-Smits Brend-Smits requested a review from a team as a code owner March 9, 2026 09:33
@Brend-Smits Brend-Smits force-pushed the fix/exact-match-was-not-really-exact-but-partial-exact branch from 187cc9d to 8018959 Compare March 9, 2026 09:39
@Brend-Smits Brend-Smits changed the title fix!: make exactMatch truly bidirectional for label matching feat: add bidirectionalLabelMatch option and deprecate exactMatch Mar 9, 2026
Introduce a new bidirectionalLabelMatch option that performs strict
two-way label matching (runner labels must equal workflow labels as a
set). This preserves the existing exactMatch behavior (unidirectional
subset check) to avoid breaking changes.

The bidirectionalLabelMatch option for runner label matching
requires labels to be identical in both directions. Previously, a runner
with labels [A, B, C, D] would match a job requesting [A, B, C] when
exactMatch was true. Now, bidirectionalLabelMatch=true requires the labels to be
exactly identical - the runner will only match if the job requests
exactly [A, B, C, D].

This change affects users who have runners with extra labels (e.g.,
on-demand) that were previously matching jobs not explicitly
requesting those labels. After this change, such runners will only
be used when jobs explicitly request all of the runner labels.

Before: Job [A,B,C] + Runner [A,B,C,D] + exactMatch=true -> Match
After:  Job [A,B,C] + Runner [A,B,C,D] + exactMatch=true -> No Match

ExactMatch was suppose to have this behaviour, but the avoid breaking
changes, the variable will be deprecated to give users time to migrate.

To migrate, use bidirectionalLabelMatch instead of exactMatch in your runner configs.
Then either:
1. Remove extra labels from runner configurations, or
2. Add the extra labels to your workflow job runs-on

Signed-off-by: Brend Smits <brend.smits@philips.com>

Co-authored-by: Stuart Pearson <stuart.pearson@philips.com>
@Brend-Smits Brend-Smits force-pushed the fix/exact-match-was-not-really-exact-but-partial-exact branch from 8018959 to e61882b Compare March 9, 2026 09:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant