🚤 Keep your action versions up-to-date by automatically promoting a
major tag (and optionally, a latest
tag) each time a release is created.
According to the github actions
versioning guide,
actions publishers should have a major tag (v1
, v2
, etc) which points to the
latest version of any minor/patch release of their action, for ease of use by
the others.
I found this process quite tedious, and repetitive which is why this action exists. If you have published an action and would like to have your action follow the same versioning structure as many others in the marketplace, then simply create a release workflow that includes this action. See the usage example.
Indicates to the action whether or not to create/update a tag called latest
pointing to the latest release. Default: "false"
.
Do you prefer creating vN
branches or vN
tags? Default: "false"
A github token used for creating an octoclient for making API calls. Default:
${{ github.token }}
.
The version of the branch/tag that was published/updated.
Was latest also published?
Deprecated in v3: Use tag
Deprecated in v3: If a non-default PAT (Personal Access Token) is needed,
use token
instead.
This action supports debug logging. When enabled, it will dump the output of the api call for creating the tags/branches. This is useful for testing and should be included when reporting bugs.
versioning.yml
name: Keep the versions up-to-date
on:
release: # (1)
types:
- released
- edited
push: # (1)
tags:
- 'v?[0-9]+.[0-9]+.[0-9]+'
branches-ignore:
- '**'
paths-ignore:
- '**'
jobs:
actions-tagger:
runs-on: windows-latest
permissions: # (2)
contents: write
steps:
- uses: Actions-R-Us/actions-tagger@v2
with:
publish_latest_tag: true
-
Add the push configuration if you want this action to also run when a new tag or branch is created. Due to the nature of releases, a new tag will also be created with a new release, which will trigger a new workflow run. Therefore, pick one or the other to avoid conflicts.
An event will not be created when more than three tags are pushed at once.
If using the push event, and you want to track branches, replace
tags
withbranches
andbranches-ignore
withtags-ignore
. At all times, leave the filter forpaths-ignore
as is. -
The
permissions
option is only required if the workflow permission for the given repository is set to readonly.readonly
permission renders the main purpose of this action useless because it will be unable to create tags. Using thecontents: write
scope allows this action to once again gain the ability to create/update tags. For more details on changing the workflow permissions for a given repository, see Configuring the defaultGITHUB_TOKEN
permissions. For more details on the various available scopes that can be configured for theGITHUB_TOKEN
, seepermissions
.It is also important to note that when modifying one scope of the permission of
GITHUB_TOKEN
, all other unspecified scopes are set to no access with the exception of themetadata
scope, which is set toread
. See Modifying the permissions for theGITHUB_TOKEN
for more details. This shouldn't be a concern for this action, because it only exclusively deals with the contents of the given repository.
- Creates a
latest
tag