GitHub Actions

Search…

GitHub Actions

Environment variables
The Authentication environment variables can be configured with Secret Variables.
In this example a publish type NPM_TOKEN is required to publish a package to the npm registry. GitHub Actions automatically populate a GITHUB_TOKEN environment variable which can be used in Workflows.
Node project configuration
​GitHub Actions support Workflows, allowing to run tests on multiple Node versions and publish a release only when all test pass.
Note: The publish pipeline must run on a Node version that meets our version requirement.
.github/workflows/release.yml configuration for Node projects
The following is a minimal configuration for semantic-release with a build running on the latest LTS version of Node when a new commit is pushed to a master branch. See Configuring a Workflow for additional configuration options.
1
name: Release
2
on:
3
  push:
4
    branches:
5
      - master
6
jobs:
7
  release:
8
    name: Release
9
    runs-on: ubuntu-latest
10
    steps:
11
      - name: Checkout
12
        uses: actions/[email protected]
13
        with:
14
          fetch-depth: 0
15
      - name: Setup Node.js
16
        uses: actions/setup-[email protected]
17
        with:
18
          node-version: 'lts/*'
19
      - name: Install dependencies
20
        run: npm ci
21
      - name: Release
22
        env:
23
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
24
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
25
        run: npx semantic-release
Copied!
Pushing package.json changes to a master branch
To keep package.json updated in the master branch, @semantic-release/git plugin can be used.
Note: Automatically populated GITHUB_TOKEN cannot be used if branch protection is enabled for the target branch. It is not advised to mitigate this limitation by overriding an automatically populated GITHUB_TOKEN variable with a Personal Access Tokens, as it poses a security risk. Since Secret Variables are available for Workflows triggered by any branch, it becomes a potential vector of attack, where a Workflow triggered from a non-protected branch can expose and use a token with elevated permissions, yielding branch protection insignificant. One can use Personal Access Tokens in trusted environments, where all developers should have the ability to perform administrative actions in the given repository and branch protection is enabled solely for convenience purposes, to remind about required reviews or CI checks.
If the risk is acceptable, some extra configuration is needed. The actions/checkout persist-credentials option needs to be false, otherwise the generated GITHUB_TOKEN will interfere with the custom one. Example:
1
- name: Checkout
2
    uses: actions/[email protected]
3
    with:
4
      fetch-depth: 0
5
      persist-credentials: false # <--- this
Copied!
Trigger semantic-release on demand
Using GUI:
You can use Manual Triggers for GitHub Actions.
Using HTTP:
Use repository_dispatch event to have control on when to generate a release by making an HTTP request, e.g.:
1
name: Release
2
on:
3
  repository_dispatch:
4
    types: [semantic-release]
5
jobs:
6
# ...
Copied!
To trigger a release, call (with a Personal Access Tokens stored in GITHUB_TOKEN environment variable):
1
$ curl -v -H "Accept: application/vnd.github.everest-preview+json" -H "Authorization: token ${GITHUB_TOKEN}" https://api.github.com/repos/[org-name-or-username]/[repository]/dispatches -d '{ "event_type": "semantic-release" }'
Copied!
Using 3rd party apps:
If you'd like to use a GitHub app to manage this instead of creating a personal access token, you could consider using a project like:
​Actions Panel - A declaratively configured way for triggering GitHub Actions
​Action Button - A simple badge based mechanism for triggering GitHub Actions