This github action create new tag based on the version number contained in the version file.
New tag is created only if:
- Version contained in the version file is in the SemVer format
- Version in the version file is higher than the last version published in a git tag
Version in git tags are always prefixed with a "v": if version file contains "1.2.3" git tag will be "v1.2.3"
Additionally, this action can be used to only check the version value in the version file; only read the versions (file and tag) or release a version that was in "pre-release". See "Inputs" for more details.
version-file
: path to the version file. Default is.VERSION
check-only
: ifyes
, no new tag will be published. The action will only validate that the version is a valid SemVer format and it's a higher version than the last version published in a tag.read-only
: ifyes
, the action will simply read the version numbers and return the values in the outputs:- version file value can be accessed with the
new-version
output - last version in git tag can be accessed with the
last-version
output.
- version file value can be accessed with the
release-only
: ifyes
, the action will try to release the version contained in the version file:- It will search in existing tags for a version matching the one in the version file with the suffix "pre-release"
- If none is found, it returns an error saying that this version does not exist in pre-release
- If found, it will publish a tag with the version contained the version file
- Ex: if the version in the version file is "1.2.3" -> it looks for a tag "v1.2.3-pre-release" and if found it will publish a new tag "v1.2.3"
suffix
: a string that will be appended to the version number in git tag:- if version in version file is "1.2.3" and suffix is "my_suffix"; the git tag will be "v1.2.3-my_suffix"
- use "pre-release" suffix to mark a version as pre-release that can later be released with the
release-only
option
check-only
, read-only
, release-only
option are mutually exclusive: only one of them can be set to yes
at the same time
new-version
: version contained in the version filelast-version
: last version found in the git tag from the repository in the SemVer format without prefix nor suffix- if the last version tag is "v1.2.3-pre-release" the value of
last-version
will be "1.2.3"
- if the last version tag is "v1.2.3-pre-release" the value of
The version tag in git will be created with "v" prefix:
- if the version file contains "1.2.3" ; the tag added in git will be "v1.2.3"
No prefix allowed in the version file:
- if the version file contains "v1.2.3" it will return an error as it is not a SemVer
Suffix delimiter is the dash -
.
A suffix can be added by using the input suffix
:
- if the version file contains "1.2.3" and the
suffix
input is "pre-release", the tag added in git will be "v1.2.3-pre-release"
No suffix is allowed in the version file:
- if the version file contains "1.2.3-pre-release" it will return an error as it is not a SemVer
Note that a version with a suffix is not newer than the same version without suffix. Bump-version compare version without suffix:
- if version file contains "1.2.3" and last version found in git tags is "1.2.3-pre-release" bump-version will return an error saying that version is not new
If you want to release a version currently in pre-release:
- Set the input
release
toyes
- bump-version will check that the last version found in git tags has a "pre-release" suffix and publish a new tag without the suffix
- You do some work
- When ready to do a PR, you edit the version file in your repository (typically
.VERSION
) according to the changes you made (major, minor or patch) - Push and create a PR
- Use
bump-version
action withcheck-only
toyes
to check that the version file has been well updated and is ready to be merged - Validate the PR and merge
- Use
bump-version
action to publish a new tag based on the version contained in the version file
- You do some work on a custom branch
feature/demo
- When ready to do a PR, you edit the version file in your repository (typically
.VERSION
) according to the changes you made (major, minor or patch) - Push and create a PR from branch
feature/demo
todev
- Use
bump-version
action withcheck-only
toyes
to check that the version file has been well updated and is ready to be merged - Validate the PR and merge
- Use
bump-version
action withsuffix
set topre-release
to publish a new tag based on the version contained in the version file with thepre-release
suffix - Create a PR from
dev
tomain
and merge - Use
bump-version
action withrelease-only
toyes
to publish the version in pre-release
With this workflow git tags will look like this:
v0.0.1-pre-release
v0.0.2-pre-release
v0.1.0-pre-release
v0.1.0
v0.1.1-pre-release
v0.1.1
v0.1.2-pre-release
v0.1.3-pre-release
v0.1.3
where only the version without the "pre-release" tag have been merged in main
branch
Check version on PR on dev
branch:
name: Check Version
on:
pull_request:
branches: [dev]
jobs:
check-version:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- id: check
name: Check Version
uses: Interstellar-Lab/[email protected]
with:
version-file: '.VERSION'
check-only: 'yes'
Publish new tag on merge in dev
branch:
name: Bump Version
on:
push:
branches: [dev]
jobs:
bump-version:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- id: check
name: Bump Version
uses: Interstellar-Lab/[email protected]
with:
version-file: '.VERSION'