Skip to content
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

Revise exclude patterns behaviour and docs #586

Open
lukpueh opened this issue May 1, 2023 · 0 comments
Open

Revise exclude patterns behaviour and docs #586

lukpueh opened this issue May 1, 2023 · 0 comments

Comments

@lukpueh
Copy link
Member

lukpueh commented May 1, 2023

Description of issue or feature request:
in-toto-run CLI and API take an "exclude pattern" argument to match file paths, which should be excluded from resulting link metadata.

While setting up an in-toto pipeline (tuf#2000) and also while refactoring related code (#584) I noticed a few issues, which are randomly listed below.

Current behavior:

  • Our docs on RTD alone do not suffice to understand proper usage, and might be inaccurate too (former is my personal experience from setting up the tuf pipeline mentioned above; latter needs checking!)
  • There are some opinionated default patterns settings.ARTIFACT_EXCLUDE_PATTERNS, which are used rather in-transparently.
  • What's the expected pattern to exclude dotfiles in CWD, i.e. when ["."] is passed as materials or products argument?
  • Should we, in terms of expected/intuitive behavior, pattern-match before or after:
    • changing base path (currently after)
    • stripping ITE-4 schemes (currently after)
    • applying os.path.normpath (currently after; does this make patterns platform-dependent?)
    • constructing the file path, i.e. dirpath + basename (currently before and after)
    • removing lstrip paths (currently before)
    • replacing backwards with forward slashes (currently before; also see #565)
  • It could be helpful to allow different patterns for materials and products.

Expected behavior:

  1. Agree on expected/intuitive behavior
  2. Make sure the implementation is correct
  3. Update docs to be useful

NOTE: I strongly suggest to fix issues based on the refactor in #584, which drastically simplifies the code, w/o changing prior behavior.

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

No branches or pull requests

1 participant