Introduce 'paths_filter' option along with new return values

[paescuj]

This introduces a new option called paths_filter which can be used to define one or more named filters with path patterns (paths_ignore, paths), inspired by the paths-filter action. When defining such filters, the action returns corresponding information in a new output called paths_result.
This makes it possible to get dedicated information about different path patterns and react accordingly, in a single run of 'skip-duplicate-actions'.
For example in a monorepo, I want to run jobs related to the "frontend" only if some files in the corresponding folder frontend/ have changed and same with "backend". This can now be achieved with the following configuration:

jobs:
  pre_job:
    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@master
        with:
          paths_filter: |
            frontend:
              paths:
                - 'frontend/**/*'
            backend:
              paths:
                - 'backend/**/*'

  frontend:
    needs: pre_job
    if: needs.pre_job.outputs.should_skip != 'true' || !fromJSON(needs.pre_job.outputs.paths_result).frontend.should_skip
    ...

  backend:
    ...

The paths_result output returns a JSON-object which looks something like this:

{
  "frontend": {
    "should_skip": true,
    "backtrack_count": 1,
    "skipped_by": {
      // Information about the workflow run
    }
  },
  "backend": {
    "should_skip": false,
    "backtrack_count": 1,
    "matched_files": ["backend/file.txt"]
  },
  "global": {
    "should_skip": false,
    "backtrack_count": 0
  }
}

If 'skip-duplicate-actions' terminates before the paths checks are performed (for example, when a successful duplicate run has been found) the paths_result returns an empty object ({}). This can be easily intercepted in the if condition of a job by checking the result of the "global" should_skip output first (see above).
The global key in the output of paths_result corresponds to the "global" paths_ignore and paths inputs, which makes it possible to profit from the information of paths_result even when only defining "global" paths_ignore and/or paths inputs.
As you can see above, the paths_result object also returns a list of matched files, if there are any, and skipped_by information.
The backtrack_count shows how many commits where traced back (skipped) until a result has been found.

The named filters in paths_filter also accept the paths_ignore setting and backtracking can optionally be disabled or limited to a number of commits, for example:

          paths_filter:
            frontend:
              paths_ignore:
                - 'frontend/readme.md'
                - 'frontend/docs/**/*'
              paths:
                - 'frontend/**/*'
              # can be a boolean or number (default: true)
              # 5 means to stop after having traced back 5 commits
              backtracking: 5

In addition, this pull request introduces the following outputs:

• changed_files: A two-dimensional array, with a list of changed files for each commit that was traced back. Returns information only if one of the options "paths_ignore", "paths" or "paths_filter" is set.
  • For example: [["some/example/file.txt", "another/example/file.txt"], ["frontend/file.txt"]]
  • Having a two-dimensional list makes processing flexible. For example, one can flatten (and uniquify) the list to get all changed files for all commits which were traced back. Or one can use changed_files[0] to get the changed files in the current commit. One might also use the output of backtrack_count to process the list of changed files.
• reason: The reason why the current run is considered skippable or unskippable.
  • For example: skip_after_successful_duplicate

This pull request contains no breaking changes and I was particularly careful to not compromise the performance of the action.

Closes #139

@fkirc If you like those changes (I really hope you do 😄), I'll happily update the README.

[fkirc]

Thanks for submitting the PR with detailed descriptions.
The changes look good, but I think that we need to split this into multiple PRs.
I suggest the following structure:

• a separate PR for dependency updates
• a separate PR for the reason output
• a separate PR for the changed_file output
• a separate PR for paths_filter/paths_result

My hope is that small chunks of functionality make it easier to upgrade this action in a safe way.

[paescuj]

Thanks for submitting the PR with detailed descriptions. The changes look good, but I think that we need to split this into multiple PRs. I suggest the following structure:

* a separate PR for dependency updates

* a separate PR for the reason output

* a separate PR for the changed_file output

* a separate PR for paths_filter/paths_result

My hope is that small chunks of functionality make it easier to upgrade this action in a safe way.

Hey @fkirc, thanks for your positive feedback! Sure, will split it up and submit separate pull requests tomorrow 👍

[paescuj]

Also, please let me know if you have better ideas about the naming of the input/output parameters.

[paescuj]

Closing in favor of new PRs (#179, #180 & others will follow soon).