3 minute read

In this page you can find the overall principles of the various Nyx phases and how they work in order to take full advantage.

Clean

In this phase, which must be invoked explicitly, the repository state is reverted to its initial state by removing all the files created during the other stages, if any.

Nyx will only clean the artifacts created by its own release process (like the changelog or the summary file) while all others are ignored.

Infer

This phase is where information is collected from the Git repository, if required. No change is applied so you may consider this a read only step.

Let’s break down the actions taken:

  1. release scope definition: the Git commit history is browsed using Git natural order (from newest to older commits) starting from the current commit in the current branch (HEAD). Each commit is inspected along with its tags and the search stops at commit C where C is the first commit with a valid release tag applied (according to the scheme in use). The release tag becomes the previous version and commit C+1 (the commit after C, which was encountered before C when stepping backward) becomes the initial commit.
  2. scope analysis: messages of commits within the release scope are analyzed against the configured conventions in order to detect whether or not there are significant changes and, if so, which version identifier must be bumped.
  3. generate version: creates the current version identifier. If, during the scope analysis, the release scope has beed detected as containing some significant changes, the previous version is increased by bumping the identifier that was inferred during the analysis (depending on the commit message convention). Otherwise the previous version is left intact. If the above steps didn’t find any previous version then the initial version is used.

By the end of this task, Nyx has all the information it needs to proceed to further steps. This information is also made available through the state.

Some of the above steps may be skipped when the user overrides their outcomes by configuration. In general, a minimal effort approach is used so these steps are only triggered when required.

When merge commits are encountered scanning the commit history Nyx follows the first parent commit to stay on the main branch.

Make

This is where the configured artifacts are built or modified by Nyx, when needed. More specifically:

  • substitutions are evaluated and text tokens are replaced in the configured files
  • the changelog is built and rendered

Mark

This phase is where:

  1. new or changed release artifacts are committed, if any and if the configured release type instructs the tool to do so
  2. a new release tag is created in the Git repository. The tag anatomy (i.e. whether it is lightweight or annotated) is driven by the release type configuration
  3. the new commit and tag are pushed to the remote repositories, if required by the release type configuration

These steps are only taken if there is a new version resulting from the commit history after inference, otherwise no action is taken.

Publish

If the matched release type configuration has the publish flag enabled the new release, if any, is published to the configured services.

These steps are only taken if there is a new version resulting from the commit history after inference, otherwise no action is taken.