Answers: <p>We have similar situations whereby you want the action to do different things based on the files changed within the commit. You could generate a list of files modified within the PR/commit (within your action) using something like (simplified for ease of reading):</p>
  <pre class="lang-bash prettyprint-override"><code># export a list of changed files
  
  export FILESCHANGED=$( curl --header 'authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' --header 'content-type: application/json' --silent https://api.github.com/repos/${{ github.repository }}/commits/${{ github.sha }} | jq '.files[].filename')
  
  # writes changed files into a text file whilst removing quotes and substituting a space for a newline (each file will appear on a separate line).
  
  echo ${FILESCHANGED} | tr -d [\&quot;] | sed 's/ /\n/g' &gt;&gt; files_changed.txt
  
  # display the list of changed files for visibility in the workflow
  
  echo &quot;Files changed in this commit&quot;
  
  cat files_changed.txt
  </code></pre>
  <p>you could then examine the list of files that are part of the commit/PR and run your logic accordingly in steps in a simple script</p>
  <pre><code>
  if C makefile is contained in the list
    run C makefile
  else
    do not run C makefile.
  
  if C makefile is contained and/or if NAPI makefile is contained 
    run NAPI makefile
  else if neither exist in list 
    do not run NAPI makefile.
  </code></pre>
  <p>Logic will then dictate what runs based on what is contained in the commit also this would turn this into a single workflow from what I can see.</p>
  <p>Hope that helps.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-04-05T15:14:13.437Z
Answers: 2022-04-05T16:05:43.363Z
Answers: 2022-04-05T16:05:43.363Z
Answers: cmsmith7
Answers: <p>So in the same repo you have separate Makefiles for both components (the core library and the add-on), but one of those components (the library) is also actually a dependency to the other.</p>
  <p>I suggest merging these into a single Makefile. In the GitHub workflow, run <code>make all</code> and use GitHub action <a href="https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows" rel="nofollow noreferrer">caching</a> so that <em>make</em> only rebuilds components if their dependencies have been modified.</p>
  <p>Then, use the <strong>concurrency</strong> feature in GitHub workflows, if you don’t want multiple runs to overlap simultaneously.</p>
  <p><a href="https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency" rel="nofollow noreferrer">https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2022-12-31T21:45:46.563Z
Answers: 2022-12-31T21:57:53.703Z
Answers: 2022-12-31T21:57:53.703Z
Answers: benjimin
Body: <p>I have a repo, in which there is one folder at the root with a Makefile to build a C library. In the same repo, there is another folder at the root with a folder with another Makefile for building a node C addon via Node-API, and a small JS/TS API using said addon. The NAPI addon is dependent on the C library.</p>
  <p>I have a workflow file for the C which runs when there is a commit on the C folder, and runs with any push or PR.
  I have another workflow file that runs when there is a commit+push/PR to the JS/TS folder, OR when the C workflow has completed successfully.</p>
  <p>My goal is (of course) to only have the minimal amount of workflows run, depending on &quot;how high in the stack the commits were&quot;. If commits touch only the C, I want both the C and NAPI addon to be checked. If commits touch only the NAPI addon, I want only the NAPI addon to be checked. If commits touch both the C and NAPI addon, I want both the C and NAPI to be checked; but for NAPI to only be checked once.</p>
  <p>For now, when the commits touch both the C and NAPI addon, the CI for the NAPI addon is launched twice: once for the commits affecting the NAPI folder, once for the successful completion of the C workflow.</p>
  <p>How do I fix this ?</p>
  <p>NB: I've tried using <code>fkirc/skip-duplicate-actions@master</code>, but it didn't do the job.</p>
  
Tags: <github><workflow><github-actions>
Title: How do I prevent a given GitHub Workflow from being launched twice from two almost simultaneous events?
UserDisplayName: Tristan Duquesne
ThreadText: # How do I prevent a given GitHub Workflow from being launched twice from two almost simultaneous events?
  
  (Asked by: username_0 on 2021-05-14)
  
  I have a repo, in which there is one folder at the root with a Makefile to build a C library. In the same repo, there is another folder at the root with a folder with another Makefile for building a node C addon via Node-API, and a small JS/TS API using said addon. The NAPI addon is dependent on the C library.
  
  I have a workflow file for the C which runs when there is a commit on the C folder, and runs with any push or PR.
  I have another workflow file that runs when there is a commit+push/PR to the JS/TS folder, OR when the C workflow has completed successfully.
  
  My goal is (of course) to only have the minimal amount of workflows run, depending on "how high in the stack the commits were". If commits touch only the C, I want both the C and NAPI addon to be checked. If commits touch only the NAPI addon, I want only the NAPI addon to be checked. If commits touch both the C and NAPI addon, I want both the C and NAPI to be checked; but for NAPI to only be checked once.
  
  For now, when the commits touch both the C and NAPI addon, the CI for the NAPI addon is launched twice: once for the commits affecting the NAPI folder, once for the successful completion of the C workflow.
  
  How do I fix this ?
  
  NB: I've tried using `fkirc/skip-duplicate-actions@master`, but it didn't do the job.
  
  **Tags:** github, workflow, github-actions
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2022-04-05. Score: 1
  
  We have similar situations whereby you want the action to do different things based on the files changed within the commit. You could generate a list of files modified within the PR/commit (within your action) using something like (simplified for ease of reading):
  
  ```bash
  # export a list of changed files
  
  export FILESCHANGED=$( curl --header 'authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' --header 'content-type: application/json' --silent https://api.github.com/repos/${{ github.repository }}/commits/${{ github.sha }} | jq '.files[].filename')
  
  # writes changed files into a text file whilst removing quotes and substituting a space for a newline (each file will appear on a separate line).
  
  echo ${FILESCHANGED} | tr -d [\"] | sed 's/ /\n/g' >> files_changed.txt
  
  # display the list of changed files for visibility in the workflow
  
  echo "Files changed in this commit"
  
  cat files_changed.txt
  
  ```
  
  you could then examine the list of files that are part of the commit/PR and run your logic accordingly in steps in a simple script
  
  ```
  
  if C makefile is contained in the list
    run C makefile
  else
    do not run C makefile.
  
  if C makefile is contained and/or if NAPI makefile is contained 
    run NAPI makefile
  else if neither exist in list 
    do not run NAPI makefile.
  
  ```
  
  Logic will then dictate what runs based on what is contained in the commit also this would turn this into a single workflow from what I can see.
  
  Hope that helps.
  
  
  ---
  
  ### Answer by username_2 on 2022-12-31. Score: 0
  
  So in the same repo you have separate Makefiles for both components (the core library and the add-on), but one of those components (the library) is also actually a dependency to the other.
  
  I suggest merging these into a single Makefile. In the GitHub workflow, run `make all` and use GitHub action [caching](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows) so that *make* only rebuilds components if their dependencies have been modified.
  
  Then, use the **concurrency** feature in GitHub workflows, if you don’t want multiple runs to overlap simultaneously.
  
  <https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency>
  
  
  ---
  
  