Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/softprops/turnstyle

🎟️A GitHub Action for serializing workflow runs
https://github.com/softprops/turnstyle

github-actions

Last synced: 6 days ago
JSON representation

🎟️A GitHub Action for serializing workflow runs

Awesome Lists containing this project

README 

        


  🎟️

  


  turnstyle






   A GitHub Action for serializing workflow runs






  

		

	








## 🤔 why bother



GitHub Actions is an event-oriented system. Your workflows run in response to events and are triggered independently and without coordination. In a shared repository, if two or more people merge pull requests, each will trigger workflows without regard to one another.



This can be problematic for workflows used as part of a continuous deployment process. You might want to let an in-flight deployment complete before progressing further with the next workflow. This is the usecase turnstyle action targets.



## 🤸 Usage



The typical setup for turnstyle involves adding job step using `softprops/turnstyle@v2`.



```diff

name: Main



on: push



jobs:

  main:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout

        uses: actions/checkout@v4

+     - name: Turnstyle

+       uses: softprops/turnstyle@v2

      - name: Deploy

        run: sleep 30

```



### Timing out



To avoid waiting prolonged periods of time, you may wish to bail on a run or continuing a workflow run regardless of the status of the previous run.



You can bail from a run using the built-in GitHub Actions [`jobs..timeout-minutes`](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes) setting



```diff

name: Main



on: push



jobs:

  main:

+   timeout-minutes: 5

    runs-on: ubuntu-latest

    steps:

      - name: Checkout

        uses: actions/checkout@v4

      - name: Turnstyle

        uses: softprops/turnstyle@v2

      - name: Deploy

        run: sleep 30

```



You can also limit how long you're willing to wait before moving on with `jobs..steps.with.continue-after-seconds`



```diff

name: Main



on: push



jobs:

  main:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout

        uses: actions/checkout@v4

      - name: Turnstyle

        uses: softprops/turnstyle@v2

        with:

+         continue-after-seconds: 180

      - name: Deploy

        run: sleep 30

```



or before aborting the step with `jobs..steps.with.abort-after-seconds`



```diff

name: Main



on: push



jobs:

  main:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout

        uses: actions/checkout@v4

      - name: Turnstyle

        uses: softprops/turnstyle@v2

        with:

+         abort-after-seconds: 180

      - name: Deploy

        run: sleep 30

```



you can also wait on a specific job (and step) to complete in a run by using the `jobs..steps.with.job-to-wait-for`

and `jobs..steps.with.step-to-wait-for` inputs. Specify the name of the job/step to wait for.



```diff

name: Main



on: push



jobs:

  main:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout

        uses: actions/checkout@v4

      - name: Turnstyle

        uses: softprops/turnstyle@v2

        with:

+         job-to-wait-for: "main"

+         step-to-wait-for: "Deploy"

      - name: Deploy

        run: sleep 30

```

 



Finally, you can use the `force_continued` output to skip only a subset of steps

by setting `continue-after-seconds` and conditioning future steps with

`if: ! steps..outputs.force_continued`



```diff

name: Main



on: push



jobs:

  main:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout

        uses: actions/checkout@v4

      - name: Turnstyle

        id: turnstyle

        uses: softprops/turnstyle@v2

        with:

+         continue-after-seconds: 180

      - name: Deploy

+       if: ! steps.turnstyle.outputs.force_continued

        run: sleep 30

```



#### inputs



| Name                     | Type    | Description                                                                                                                            |

| ------------------------ | ------- |----------------------------------------------------------------------------------------------------------------------------------------|

| `continue-after-seconds` | number  | Maximum number of seconds to wait before moving forward (unbound by default). Mutually exclusive with abort-after-seconds              |

| `abort-after-seconds`    | number  | Maximum number of seconds to wait before aborting the job (unbound by default). Mutually exclusive with continue-after-seconds         |

| `poll-interval-seconds`  | number  | Number of seconds to wait in between checks for previous run completion (defaults to 60)                                               |

| `same-branch-only`       | boolean | Only wait on other runs from the same branch (defaults to true)                                                                        |

| `initial-wait-seconds`   | number  | Total elapsed seconds within which period the action will refresh the list of current runs, if no runs were found in the first attempt |

| `job-to-wait-for`        | string  | Name of the workflow's job to wait for (unbound by default).                                                                           |

| `step-to-wait-for`       | string  | Name of the step to wait for (unbound by default). Required if job-to-wait-for is set.                                                 |



#### outputs



| Name              | Type    | Description                                                                                     |

| ----------------- | ------- | ----------------------------------------------------------------------------------------------- |

| `force_continued` | boolean | True if continue-after-seconds is used and the step using turnstyle continued. False otherwise. |



## required permissions



Because this application leverages the `GITHUB_TOKEN` to make API requests, the

permissions granted to the token must be sufficient to make the API requests.

By default, the token has wide enough permissions to allow all API requests

made by this action. If you are customizing your token permissions, you must

explicitly specify all permissions, including those that you need that would

otherwise be granted by the defaults. See ["Permissions for the

GITHUB_TOKEN"](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)

In the GitHub Actions documentation.



If you need to specify explicit permissions for the API requests made by this

action, the permissions required are:



- `actions:read` - this permission is required for the [listWorkflowRunsForRepo](https://octokit.github.io/rest.js/v18#actions-list-workflow-runs-for-repo)

  API request.



## cost of coordination



At this time there is no way to coordinate between workflow runs beyond waiting. For those using private repositories, [you are charged based on the time your workflow spends running](https://github.com/features/actions#pricing-details). Waiting within one workflow run for another to complete will incur the cost of the time spent waiting.



Doug Tangren (softprops) 2020