Skip using paths_filter: pre job logs it will skip target jobs but target jobs still run

[jkarstens]

I am following Example 3 from the README, but I am struggling to get jobs actually skipped. I am in a monorepo and want to do exactly as the documented example suggests: only run frontend checks when frontend files are updated and only run backend checks when backend files are updated.
In my GitHub Branches settings I have the three status checks (pre, api, and ui) marked as required.

I put up a test PR that contained a change to a file in neither the frontend nor the backend, so I expected both checks to be skipped and the status checks to pass. In the Actions log, the pre job is logging that it is going to skip both checks, as expected. However, I can see from the Action logs that both steps do in fact continue to run - why is this? How can I skip them?
pre job log:

api job log:

ui job log:

The workflow file:

name: Format, compile, and lint
on:
  pull_request:
    branches:
      - main
  push:
    branches:
      - main

jobs:
  pre:
    runs-on: ubuntu-latest
    outputs:
      should_skip: ${{ steps.skip_check.outputs.should_skip }}
      paths_result: ${{ steps.skip_check.outputs.paths_result }}
    steps:
      - id: skip_check
        uses: fkirc/skip-duplicate-actions@v5
        with:
          paths_filter: |
            api:
              paths_ignore:
                - 'api/api/migrations/**'
              paths:
                - 'api/**/*.py'
            ui:
              paths:
                - 'ui/src/**/*.[jt]sx?'

  api:
    needs: pre
    if: needs.pre.outputs.should_skip != 'true' || !fromJSON(needs.pre.outputs.paths_result).api.should_skip
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: psf/black@stable
        with:
          options: '--check --color --diff --extend-exclude api/api/migrations --verbose'
          src: './api'
          version: '22.12.0'
      - uses: actions/setup-python@v4
        with:
          python-version: '3.8.13'
      - uses: py-actions/flake8@v2
        with:
          args: '--extend-ignore=E203'
          exclude: 'api/api/migrations'
          flake8-version: '6.0.0'
          max-line-length: '88'

  ui:
    needs: pre
    if: needs.pre.outputs.should_skip != 'true' || !fromJSON(needs.pre.outputs.paths_result).ui.should_skip
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - name: Compile, lint, and format
        run: |
          cd ui
          yarn
          yarn generate-env-file
          yarn tsc
          npx eslint .
          yarn prettier .

I tried removing the global should_skip check from the api and ui jobs, but then no checks at all ran (not even the pre check) which put me back to the original problem.

[q0w]

Any news?

I get global should_skip = true and !fromJSON(needs.pre.outputs.paths_result).api.should_skip = true for some reason. So api job is never skipped

[fkirc]

I apologize for the late answer.
For future readers of this issue:

If you run into problems with the paths_filter option, then I would recommend to copy the example 1 multiple times according to your needs: https://github.com/fkirc/skip-duplicate-actions#example-1-skip-entire-jobs

With the example 1, there is no need for any JSON-parsing, instead you can check the global should_skip output.
Normally, the example 1 can be copied and adapted for every sub-job where a skip-behavior is needed.

[fkirc]

I am closing this issue because of PR https://github.com/fkirc/skip-duplicate-actions/pull/336/files , please re-open if needed

[q0w]

@fkirc but is it a bug or expected behaviour?

[paescuj]

@fkirc but is it a bug or expected behaviour?

Happy to take a look at it if you can provide some logs 👍

[q0w]

@fkirc but is it a bug or expected behaviour?

Happy to take a look at it if you can provide some logs 👍

I had the exact same issue as above. Now I'm using 2 steps without paths_filter as a workaround.

[fkirc]

Let‘ reopen the issue because my proposed solution seems to be only a workaround