Skip to content

GitHub Action

The official GitHub Action can be used to configure Uplift within your workflow. As Uplift is designed to push changes back to your repository, you will need to provide it with an access token1. This is by design.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# .github/workflows/ci.yml

name: ci
on:
  push:
    branches:
      - main
  pull_request:
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0 # (1)
      # Additional steps specified here
      - name: Release
        if: github.ref == 'refs/heads/main'
        uses: gembaadvantage/uplift-action@v2.0.1
        with:
          args: release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # (2)
  1. Setting a fetch-depth of 0 will ensure all tags are retrieved, which is required by Uplift to determine the next semantic version
  2. When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN will not create a new workflow run.

Triggering another Workflow

To ensure Uplift triggers another workflow run when tagging the repository, a personal access token should be created and stored as a secret. This will then replace the default GITHUB_TOKEN as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# .github/workflows/ci.yml

name: ci
on:
  push:
    branches:
      - main
  pull_request:
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
      # Additional steps specified here
      - name: Release
        if: github.ref == 'refs/heads/main'
        uses: gembaadvantage/uplift-action@v2.0.1
        with:
          args: release
        env:
          GITHUB_TOKEN: ${{ secrets.GH_UPLIFT }}

  1. It is best security practice to create an access token with the shortest possible expiration date. ↩