Changie - Replacments and Choices

Replacements

Odds are, if you are working on a large project or you are part of a team you are going to use more than one language. You might run python for machine learning, react on the frontend, ruby on rails for the backend and some java spring services sprinkled in. This on its own is not a problem, as engineers we have many solutions for this such as docker or kubernetes.

These tools will all have slight variations on how you might need to prepare and deploy a release. One thing in common is supplying release notes for a shared changelog. For this reason it was important that Changie work across as many languages as possible. One way this is achieved is with the replacement configurations. This configuration allows changie to update files with the newly prepared version as part of the build process. It works very similarly to sed with go templates for the version values.

NodeJS

Lets run through some examples, for NodeJS projects you will include the project version in the package json file. To have Changie update this value when you batch your release notes you can use the config below ( also seen on the docs here )

replacements:
  - path: package.json
    find: '  "version": ".*",'
    replace: '  "version": "{{.VersionNoPrefix}}",'

Python

There are many ways projects define the versions in python projects so I can't go over all of them. But one common method used by fastAPI is to create a version attribute in either a __init__.py or __main__.py file at the root of your project. For example here is where the version is defined for FastAPI. This can be updated with a configuration similar to this:

replacements:
  - path: "fastapi/fastapi/__init__.py"
    find: '__version__ = ".*"'
    replace: '__version__ = "{{.VersionNoPrefix}}"'

Rust

The cargo toml file includes a version field so the replacement for that would look like:

replacements:
  - path: "cargo.toml"
    find: 'version = ".*"'
    replace: 'version = "{{.VersionNoPrefix}}"'

These are just a few examples, you can of course include multiple replacements and it should work for any language.

Choices

Changie will prompt the user for answers to two questions, if enabled anyway, when creating a new change fragment. These are kind and body. Kind is associated with the type of change such as added, fixed, removed, or deprecated. Kind configuration allows setting labels, headers and formats.

The second question is the body of the change. This to can be disabled globally or per kind. You may want to disable this for certain kinds of changes that require more specific prompts.

Custom choices can be configured to add additional prompts to provide additional information for each change fragment. These choices are added to a custom map that can be used in the change format.

A short example is the one from Changie itself that asks for an issue number and adds a link when formatting. Changie's .changie.yaml is basically the default configuration with the issue choice added.

changeFormat: '* [#{{.Custom.Issue}}](https://github.com/miniscruff/changie/issues/{{.Custom.Issue}}) {{.Body}}'
custom:
- key: Issue
  type: int
  minInt: 1

Another idea is to include a link to the author at the end.

# config yaml
custom:
- key: Author
  type: string
  minLength: 3
changeFormat: '* {{.Body}} fixed by [@{{.Custom.Author}}](https://github.com/{{.Custom.Author}})

Custom choices can also be used in the header and footer formats. Such as including authors in the footer.

custom:
- key: Author
  type: string
  minLength: 3
footerFormat: |
  ### Contributors
  {{- range (customs .Changes "Author" | uniq) }}
  * [{{.}}](https://github.com/{{.}})
  {{- end}}

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