feat: add bidirectionalLabelMatch option and deprecate exactMatch#5031
Open
Brend-Smits wants to merge 3 commits intomainfrom
Open
feat: add bidirectionalLabelMatch option and deprecate exactMatch#5031Brend-Smits wants to merge 3 commits intomainfrom
Brend-Smits wants to merge 3 commits intomainfrom
Conversation
Contributor
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
34b7069 to
f597650
Compare
f86dfa0 to
7a14043
Compare
187cc9d to
8018959
Compare
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>
8018959 to
e61882b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Introduce a new
bidirectionalLabelMatchoption that performs strict two-way label matching (runner labels must equal workflow labels as a set). This preserves the existingexactMatchbehavior (unidirectional subset check) to avoid breaking changes.Problem
The
bidirectionalLabelMatchoption 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]whenexactMatchwastrue. Now,bidirectionalLabelMatch=truerequires 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.exactMatchwas supposed to have this behavior, but to avoid breaking changes, the variable will be deprecated to give users time to migrate.Changes
bidirectionalLabelMatchtoMatcherConfiginterface (optional, defaults tofalse)canRunJobto support bidirectional matching when enabledexactMatchin Terraform variables with migration guidancebidirectionalLabelMatchto multi-runner and webhook variable typesenable_runner_bidirectional_label_matchMigration
To migrate, use
bidirectionalLabelMatchinstead ofexactMatchin your runner configs. Then either:runs-onCo-authored-by: Stuart Pearson stuart.pearson@philips.com