Git-Based Semantic Versioning

This action produces a semantic version for a repository using the repository's git history.

This action is designed to facilitate assigning version numbers during a build automatically while publishing version that only increment by one value per release. To accomplish this, the next version number is calculated along with a commit increment indicating the number of commits for this version. The commit messages are inspected to determine the type of version change the next version represents. Including the term (MAJOR) or (MINOR) in the commit message alters the type of change the next version will represent.

Usage

- uses: paulhatch/semantic-version@v3
  with:
    # The branch to count commits on
    branch: "master"
    # The prefix to use to identify tags
    tag_prefix: "v"
    # A string which, if present in a git commit, indicates that a change represents a
    # major (breaking) change
    major_pattern: "(MAJOR)"
    # Same as above except indicating a minor change
    minor_pattern: "(MINOR)"
    # A string to determine the format of the version output
    format: "${major}.${minor}.${patch}-prerelease.${increment}"
    # Optional path to check for changes. If any changes are detected in the path the
    # 'changed' output will true. Enter multiple paths separated by spaces.
    change_path: "src/my-service"
    # Named version, will be used as suffix for name version tag
    namespace: project-b

Using Multiple Versions in the Same Repository

It is possible to create additional versions for multiple project co-existing in one repository, for example you may have a Helm chart, database migration, or simply be hosting multiple projects in the same repository and want them to be versioned independently. There are a few settings that can be used to accomplish this:

First, you can set the change_path input to specify a path that will be inspected for changes. Commits which do no change any files in this path will not increase the increment output. In addition, if there are no changes in a given commit with this path specified, the changed value will be false.

Second, the input namespace can be set to create an additional named version. If this value is set, it will be appended to the end of tags for the version, and only tags with this value appended will be considered when determining the version.

Finally, set different values for major_pattern and minor_pattern than the other projects in order to be able to mark these commits independently.

To use secondary versions in a workflow, simply create additional steps in a job referencing semantic version multiple times. For example:

- name: Application Version
  id: version
  uses: paulhatch/semantic-version@v3
  with:
    change_path: "src/service"
- name: Database Version
  id: db-version
  uses: paulhatch/semantic-version@v3
  with:
    major_pattern: "(MAJOR-DB)"
    minor_pattern: "(MINOR-DB)"
    change_path: "src/migrations"
    namespace: db