Github Action for the OSS license auditor project (olAudit
).
For documentations please refer to the main repository.
Example (uses Github's default token, scoped to the repository that runs it)
name: Audit licenses
on:
pull_request:
branches: [ master ] # Update to your branch name
jobs:
audit-licenses:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: OSS License Auditor
uses: digi-wolk/olaudit-action@v1
with:
path: .
comment-on-pr: true
github-token: ${{ secrets.GITHUB_TOKEN }}
In order to avoid facing GitHub API rate limits, we use Github Action's default token which is set
as ${{ github.token }}
. You can also manually set this default value to either
${{ secrets.GITHUB_TOKEN }}
or ${{ github.token }}
.
This token is automatically generated by GitHub and is scoped to the repository that is currently running the action,
and does not have enough permission to comment on the Pull Request. You can override this token with a personal
access token (PAT) with a limited scope.
To create a PAT on Github:
- Go to your Github settings
- Open Developer settings
- Open Personal access tokens
- Open Fine-grained access
- Click on Generate new token
- Select the necessary permissions
- Click on Generate token
I recommend to use fine-grained access rights limited to one repository and only for commenting on Pull Requests:
After having created the token, you can add it as a secret to your repository:
- Go to your repository
- Open Settings
- Open Secrets
- Click on New repository secret
- Add the token as a secret
- Use the secret name in your workflow file (i.e.
GH_PAT
)
Example with Personal Access Token (PAT):
name: Audit licenses
on:
pull_request:
branches: [ master ] # Update to your branch name
jobs:
audit-licenses:
runs-on: ubuntu-latest
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_PAT }}
steps:
- uses: actions/checkout@v2
- name: OSS License Auditor
uses: digi-wolk/olaudit-action@v1
with:
path: .
comment-on-pr: true
github-token: ${{ secrets.GH_PAT }}
Name | Required | Default | Description |
---|---|---|---|
path | yes | . | Path to the project root directory |
only-risky | no | false | Only show risky licenses |
fail-on-risky-fail | no | false | Fail if risky licenses that are supposed to fail are found |
comment-on-pr | no | false | Comment findings on the Pull Request |
verbose | no | false | Show verbose output (debugging) |
github-token | no | GitHub token to use for commenting on PRs |
Code owners can create a release by tagging the version as follows: First create a major release branch from the master branch and push it:
git checkout -b release/v1
git push origin release/v1
Or checkout to it if it already exists and pull the latest changes:
git checkout release/v1
git pull origin release/v1
If needed, you can fetch changes from master back to the release branch:
git checkout release/v1
git merge master
git push origin release/v1
Then create a tag and push it to the release branch:
# Update the version before running the command
RELEASE_VERSION="v1.0.0"
git tag "${RELEASE_VERSION}" -m "Minor release: ${RELEASE_VERSION}"
git push origin "${RELEASE_VERSION}"
Then move the major version tag (for example v1) to point to the Git ref of the current release:
git tag -fa v1 -m "Major release: v1"
git push origin v1 --force
Then remember to push to Github Marketplace by releasing manually from the GUI.