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

exclude files or dir #106

Open
saar-win12 opened this issue Oct 3, 2021 · 3 comments
Open

exclude files or dir #106

saar-win12 opened this issue Oct 3, 2021 · 3 comments

Comments

@saar-win12
Copy link

hey,
it is possible to use it with exclude dir?
like any why do what you need to do?

  - uses: dorny/paths-filter@v2
    id: filter
    with:
      filters: |
        src:
          - 'src/${{ matrix.services }}/**'
        ignore:
          - 'src/a/**'
          - 'src/b/**'
          - 'src/c/**'

steps.filter.outputs.src == 'true' || steps.filter.outputs.ignore == 'true'

@Obi-Dann
Copy link

Ignoring is supporting by picomatch, so should be possible in theory?
See the ignore option - https://github.com/micromatch/picomatch#picomatch-options

@Obi-Dann
Copy link

Obi-Dann commented Mar 1, 2022

I ended up forking and replacing picomatch with micromatch https://github.com/AurorNZ/paths-filter. Not sure there's an interest of creating a PR for this repo because it's a serious breaking change
With micromatch, it's possible to ignore paths in a similar way as in .gitignore
for example the following matches all .ts files excluding .test.ts files

src:
      - 'src/**/*.ts'
      - '!src/**/*.test.ts'

@cpglsn
Copy link

cpglsn commented May 20, 2023

I've worked around this with an extra bash step:

- name: Check if other files have changed
  run: |
    if [ $(echo '${{ steps.filter.outputs.all_files }}' | jq .[] | sed '/src\/a\/\|src\/b\/\|src\/c\//d' | wc -l ) -gt 0 ]; then
      echo "OTHER_FILES_CHANGED=true" >> $GITHUB_ENV
    else
      echo "OTHER_FILES_CHANGED=false" >> $GITHUB_ENV
    fi

- name: Do something
  if: steps.filter.outputs.src == 'true' && env.OTHER_FILES_CHANGED == 'true'

You need list-files: 'json' in the dorny/paths-filter step and jq to be available in your runner.

The idea is that you get the list of changed files, and whatever line match your sed expression gets removed from such list (the ignored files). If no lines are left, it means you only had ignored files been modified (OTHER_FILES_CHANGED=false), otherwise not ignored files were modified (OTHER_FILES_CHANGED=true). Then you check in the if statement of the next job which one happened.

jszwedko added a commit to vectordotdev/vector that referenced this issue Jul 7, 2023
Currently this causes all integration tests to run on common dependabot changes to
`lib/vector-core/Cargo.toml` even though those changes are likely to be very low risk. These tests
also fail due to dependabot not having access to secrets but that is being addressed separately; the
primary argument in this PR is that the tests aren't needed in the PR, just the merge queue, for changes to `Cargo.toml` due to the low risk.

I had originally just wanted to exclude only `lib/vector-core/Cargo.toml` but this wasn't possible
due to a lack of support by the paths-filter action
(dorny/paths-filter#106). Upon reflection, I think it is is unlikely that
core changes will cause integration test failures that don't also cause other test failures so my
proposal is that we just rely on the merge queue to catch that scenario. If we find it to be the
contrary, we can add it back.

Signed-off-by: Jesse Szwedko <jesse.szwedko@datadoghq.com>
jszwedko added a commit to vectordotdev/vector that referenced this issue Jul 7, 2023
Currently this causes all integration tests to run on common dependabot changes to
`lib/vector-core/Cargo.toml` even though those changes are likely to be very low risk. These tests
also fail due to dependabot not having access to secrets but that is being addressed separately; the
primary argument in this PR is that the tests aren't needed in the PR, just the merge queue, for changes to `Cargo.toml` due to the low risk.

I had originally just wanted to exclude only `lib/vector-core/Cargo.toml` but this wasn't possible
due to a lack of support by the paths-filter action
(dorny/paths-filter#106). Upon reflection, I think it is is unlikely that
core changes will cause integration test failures that don't also cause other test failures so my
proposal is that we just rely on the merge queue to catch that scenario. If we find it to be the
contrary, we can add it back.

Signed-off-by: Jesse Szwedko <jesse.szwedko@datadoghq.com>
github-merge-queue bot pushed a commit to vectordotdev/vector that referenced this issue Jul 7, 2023
Currently this causes all integration tests to run on common dependabot
changes to
`lib/vector-core/Cargo.toml` even though those changes are likely to be
very low risk. These tests
also fail due to dependabot not having access to secrets but that is
being addressed separately; the
primary argument in this PR is that the tests aren't needed in the PR,
just the merge queue, for changes to `Cargo.toml` due to the low risk.

I had originally just wanted to exclude only
`lib/vector-core/Cargo.toml` but this wasn't possible
due to a lack of support by the paths-filter action
(dorny/paths-filter#106). Upon reflection, I
think it is is unlikely that
core changes will cause integration test failures that don't also cause
other test failures so my
proposal is that we just rely on the merge queue to catch that scenario.
If we find it to be the
contrary, we can add it back.

Signed-off-by: Jesse Szwedko <jesse.szwedko@datadoghq.com>

Signed-off-by: Jesse Szwedko <jesse.szwedko@datadoghq.com>
github-merge-queue bot pushed a commit to vectordotdev/vector that referenced this issue Jul 7, 2023
Currently this causes all integration tests to run on common dependabot
changes to
`lib/vector-core/Cargo.toml` even though those changes are likely to be
very low risk. These tests
also fail due to dependabot not having access to secrets but that is
being addressed separately; the
primary argument in this PR is that the tests aren't needed in the PR,
just the merge queue, for changes to `Cargo.toml` due to the low risk.

I had originally just wanted to exclude only
`lib/vector-core/Cargo.toml` but this wasn't possible
due to a lack of support by the paths-filter action
(dorny/paths-filter#106). Upon reflection, I
think it is is unlikely that
core changes will cause integration test failures that don't also cause
other test failures so my
proposal is that we just rely on the merge queue to catch that scenario.
If we find it to be the
contrary, we can add it back.

Signed-off-by: Jesse Szwedko <jesse.szwedko@datadoghq.com>

Signed-off-by: Jesse Szwedko <jesse.szwedko@datadoghq.com>
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

3 participants