DEV Community

Cover image for Changie - Auto mode and GitHub action
miniscruff
miniscruff

Posted on

Changie - Auto mode and GitHub action

Auto Mode

Using Changie for changelog management has a lot of advantages, but one thing that has been missing is a feature that is used a lot by commit message based standards such as conventional commits which is. Automatic version bumping based on changes. That is, if I add a new feature specified by the feat prefix, conventional commit knows to bump the minor version. If I instead used the fix prefix, it knows to bump the patch version.

Changie now supports this as an optional feature by using changie batch auto or changie next auto and it works by looking at the kind configs for the unreleased changes.

When creating a new project, the changie init command will include the defaults below for auto values.

kinds:
  - label: Added
    auto: minor
  - label: Changed
    auto: major
  - label: Deprecated
    auto: minor
  - label: Removed
    auto: major
  - label: Fixed
    auto: patch
  - label: Security
    auto: patch
Enter fullscreen mode Exit fullscreen mode

This feature allows you to pretty safely execute changie batch auto && changie merge whenever you want to release instead of checking what changes are included and what the next version should be. And because this is an automatic change, any CI/CD processes you have can now go from 1 input to 0.

GitHub Action

Another thing that can help with using Changie in your project is the new changie GitHub action which can be used to run changie commands directly from your GitHub action pipelines.

A good example of using the Changie action is in the action itself, which uses Changie for changelogs and itself to batch and merge new versions. Quite the recursive project.

Here is a snippet of the full workflow

- name: Batch changes
  uses: ./
  with:
    version: latest
    args: batch auto

- name: Merge changes
  uses: ./
  with:
    version: latest
    args: merge
Enter fullscreen mode Exit fullscreen mode

The full workflow for this is to generate a pull request with an updated changelog by running batch and merge, we also use the latest version as part of the commit message and pull request summary. This is also very similar to a workflow changie uses for itself, however, changie just runs the equivalent go run main.go * commands rather then the changie action.

name: Generate release pull request

# empty workflow dispatch as we want it to be a manually run 
# action, but we have no arguments for it
on:
  workflow_dispatch: 

jobs:
  generate-pr:
    runs-on: ubuntu-20.04
    steps:
    - name: Checkout
      uses: actions/checkout@v3

    # any custom build commands you want to include goes here

    - name: Batch changes
      uses: miniscruff/changie-action@v1
      with:
        version: latest # latest is the default and can be left out
        args: batch auto

    - name: Merge changes
      uses: miniscruff/changie-action@v1
      with:
        args: merge

    - name: Get the latest version
      # id is used to reference our latest version
      # in the next step
      id: latest 
      uses: miniscruff/changie-action@v1
      with:
        args: latest

    - name: Create Pull Request
      uses: peter-evans/create-pull-request@v4
      with:
        title: Release ${{ steps.latest.outputs.output }}
        branch: release/${{ steps.latest.outputs.output }}
        commit-message: Release ${{ steps.latest.outputs.output }}
Enter fullscreen mode Exit fullscreen mode

That is all for now. Reach me on twitter @miniScruffDev or by starting a discussion on GitHub.

Top comments (2)

Collapse
 
cicirello profile image
Vincent A. Cicirello

First, very cool tool. I just added trying it out to my to-do list. It looks like it can be very useful for managing changelog. Currently, I update my changelog manually in most of my projects, although I use GitHub Actions to automate most other things that can be automated.

Anyway, one of your defaults is inconsistent with SemVer. The SemVer specification requires bumping the minor version for deprecations. See number 7 in the specification, quoted here:

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

Collapse
 
miniscruff profile image
miniscruff

Thanks for bringing this up, this is now fixed with v1.11.1