GitHubPullRequest labels filter - how to find any label instead of all?

[tavin]

Consider the following ResourceSetInputProvider:

apiVersion: fluxcd.controlplane.io/v1
kind: ResourceSetInputProvider
metadata:
    ...
spec:
  filter:
    labels:
      - buildme
      - deployme
  type: GitHubPullRequest
  url: https://github.com/...

The intention was to trigger a ResourceSet (for a build workflow) if either label was present.

Instead, both labels are now required.
I think the docs aren't clear on this but I prefer to ask:

What would people think of changing the behavior, or expanding the filter spec? For example, anyLabel: [a, b].

[matheuscscp]

I think a new field under .spec.filter would be best for this

[Nickalus12]

Yeah, the current logic definitely treats that list as a strict AND condition. I believe it follows the additive pattern common in K8s-style selectors, even though the syntax here is a simple list rather than a map.

I wouldn't change the current labels behavior since that’s a breaking change for anyone relying on that exact match, but expanding the spec is a great idea. Adding an anyLabel field or supporting something like matchExpressions would bring it much closer to standard Kubernetes filtering and solve the OR logic issue you're hitting.

I’d suggest opening a feature request for this. Most PR-based workflows eventually hit this wall where they need "any" rather than "all" labels to trigger a specific build or deployment. lmk if that makes sense.

[matheuscscp]

The current semantics comes from GitLabMergeRequest. The GitLab API call receives the list of labels and implements the filtering on the server side. GitHub does not support the same, so we implemented the filtering on the client (operator) side. Given that, I'm not against adding a new field for more advanced filtering. But since it's a list of strings and not a map, matchExpressions as is will unfortunately not fit well :(

[Nickalus12]

Ah, didn't realize the GitLab side was doing server-side filtering with that same list. Yeah, matchExpressions won't work cleanly with flat string lists. Maybe something simpler like a labelSelector field with an explicit matchPolicy: Any | All would keep it readable without forcing the K8s expression syntax.

[1happybot]

Have hit the same issue with Github PR's.
Workaround was to use different ResourceSet and ResourceSetInputProvider for each label.

Would love to get a anyLabel: [a, b] option for Github PRs.