Skip to content

Consider changing RootPathFilter to accept pattern matching #1040

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jlperkins opened this issue May 8, 2025 · 1 comment
Open

Consider changing RootPathFilter to accept pattern matching #1040

jlperkins opened this issue May 8, 2025 · 1 comment
Labels
accepted We are working on this and hope to release it into the product

Comments

@jlperkins
Copy link
Contributor

We have a request to change RootPathFilter's accepted values from a semicolon-separated list of path prefixes, to file matching patterns. This would help 1ES PT to seamlessly route through the correct files for validation for customers that download pipeline artifacts. This would be a breaking change for us if we replace RootPathFilter. We could consider adding a new option instead of replacing this one, to avoid introducing a breaking change.

@jlperkins jlperkins added the needs triage Default status upon issue submission label May 8, 2025
@katydecorah
Copy link

Thanks for starting this issue, Jules!

I think the tool would need to keep the current behavior of RootPathFilter where it accepts semicolon-separated list of path prefixes since this is the pattern used for downloading partial artifacts drops, and then add the ability to accept file matching (glob patterns), for customers that download partial drops with DownloadPipelineArtifacts, itemPattern property.

I'm not sure if it's too complex to make RootPathFilter to support both types of patterns or to introduce a new property to support file matching patterns.

1ES PT currently has about 500 pipelines that use itemPattern with DownloadPipelineAritfacts. Our goal is to eventually enable SbomValidationFailureEventAction: fail on all release pipelines, and this is a blocker.

The alternative would be for the customer to define both patterns, but this would be nearly impossible to enforce for existing customers and would add significant development toil in translating the two matching patterns.

@DaveTryon DaveTryon added accepted We are working on this and hope to release it into the product and removed needs triage Default status upon issue submission labels May 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted We are working on this and hope to release it into the product
Projects
None yet
Development

No branches or pull requests

3 participants