feat: Add support for reusable workflows and previous run attempts

.github/workflows/caller-workflow-for-testing.yml

@@ -0,0 +1,12 @@
+name: Calling Workflow Test
+
+on:
+  pull_request:
+  push:
+    branches:
+      - master
+
+jobs:
+  # This job calls the reusable workflow.
+  call_reusable_workflow:
+    uses: ./.github/workflows/reusable-workflow-for-testing.yml

.github/workflows/reusable-workflow-for-testing.yml

@@ -0,0 +1,25 @@
+name: Reusable Workflow Test
+
+on:
+  workflow_call:
+
+jobs:
+  reusable_job:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+
+      - name: Skip duplicate runs
+        id: skip_check
+        uses: ./
+        with:
+          # When this workflow is re-run (e.g. manually), the previous successful attempt should cause this to be skipped.
+          include_previous_attempts_of_same_run: 'true'
+          skip_after_successful_duplicate: 'true'
+          # avoid skipping because of other concurrent runs of this workflow.
+          concurrent_skipping: 'never'
+
+      - name: A step that runs
+        if: ${{ steps.skip_check.outputs.should_skip != 'true' }}
+        run: echo "This step should only run on the first attempt of this reusable workflow."

README.md

@@ -147,6 +147,20 @@ One of `never`, `same_content`, `same_content_newer`, `outdated_runs`, `always`.
 
 **Default:** `'never'`
 
+### `reusable_workflow_filepath`
+**EXPERIMENTAL**
+Setting this will retrieve the most recent 100 workflow runs that reference the specified reusable workflow file and substitute it for the usual list of workflow runs to check for matching tree hashes. If you reference a reusable workflow that behaves differently in different contexts, this will still skip the calling workflow for any successful run against the same context. Due to the limitations of the GitHub Actions API you must manually specify the full filepath of the reusable workflow.     
+
+Example (reusable workflow in the same repo): `'.github/workflows/my-reusable-workflow.yml'`
+Example (reusable workflow in a different repo): `'OTHER_ORG/OTHER_REPO/.github/workflows/my-reusable-workflow-from-a-different-repo.yml'`
+Default: `undefined`
+
+### `include_previous_attempts_of_same_run`
+
+If set to true, previous attempts to run the current workflow run are considered in the skip duplicate checks.
+
+Default `'false'`
+
 ## Outputs
 
 ### `should_skip`
@@ -300,7 +314,6 @@ jobs:
 > [!WARNING]  
 > If the paths_filter option is not working correctly, then you could copy the “example 1" multiple times according to your needs (see <https://github.com/fkirc/skip-duplicate-actions/issues/326> for details).
 
-
 The `paths_filter` option can be used if you have multiple jobs in a workflow and want to skip them based on different [`paths_ignore`](#paths_ignore) / [`paths`](#paths) patterns. When defining such filters, the action returns corresponding information in the [`paths_result`](#paths_result) output.
 For example in a monorepo, you might want to run jobs related to the "frontend" only if some files in the corresponding "frontend/" folder have changed and the same for "backend". This can be achieved with the following configuration:
 

action.yml

@@ -40,6 +40,13 @@ inputs:
     description: 'If true, make the workflow logs shorter'
     required: false
     default: 'false'
+  reusable_workflow_filepath:
+    description: 'Use this if you want to skip duplicate runs of a reusable workflow, even when they were called from a different parent workflow. This should be the full path of the workflow from the repo root. For reusable workflows in a different repo, ensure that you specify the full path including organisation and repo name.'
+    required: false
+  include_previous_attempts_of_same_run:
+    description: 'If set to true, previous attempts to run the current workflow run are considered in the skip duplicate checks.'
+    required: false
+    default: 'false'
 outputs:
   should_skip:
     description: 'Returns true if the current run should be skipped according to your configured rules'