mooltiverse/Nyx GitHub Action

Automatic semantic release management

View on GitHub

Trust Signals

Scorecard Score
not yet scored
Maintenance Recency
Activelast commit Jun 3, 2026
License
Apache 2.0

Pinned Snippet

workflow.ymlSHA-pinned
uses: mooltiverse/nyx@08d2649392d10bc2bb1dfe382f9b0ca5d42dc2c6 # 3.1.7

tags can be moved; commit SHAs can't. why a SHA?

namedescriptionrequireddefault
commandSelects which Nyx command to run. Allowed values are: 'clean', 'infer' (default), 'make', 'mark', 'publish'. When selecting 'infer' Nyx will only read the repository and give you back the inferred version. 'make' will build the changelog, 'mark' will apply tags, 'make' commits and push changes to the remote repository. 'publish' will publish the release to the configured servicesnoinfer
bumpInstructs Nyx on which identifier to bump on the past version in order to build the new version. This option prevents Nyx to infer the identifier to bump from the commit historyno
changelogPathThe absolute or relative path to a local file where the changelog is saved when generated. If a file already exists at the given location it is overwritten. Setting this value also enables the changelog creation, which is to say, when this option is not defined no changelog is generated. A common value used for this option is CHANGELOG.mdno
changelogTemplateThe absolute or relative path to a local file to use as a template instead of the Nyx built-in. The file must contain a valid Handlebars template (Mustache templates are also supported). Template functions can be used in custom templatesno
commitMessageConventionsEnabledThe comma separated list of commit message convention names that are enabled for the project. Here you can enable or disable the various conventions, either custom or default. The list of available conventions is defined by the configured preset or a configuration fileno
configurationFileThis option allows you to load a configuration file from a location other than default ones. This can be a relative (to the Action working directory) path to a local file or an URL to load a remote file. This configuration file can override other options, as per the evaluation order, and can be authored as .yaml (or .yml) or .json (the format is inferred by the file extension or JSON is used by default) just like the default configuration filesno
directorySets the working directory for Nyx. The directory is where Nyx searches for the Git repository and is also used as the base path when relative paths to local files or directories. By default Nyx uses the Action working directory for this. Paths defined here must be relative to the Action working directoryno
dryRunWhen this flag is set to true no action altering the repository state, either local or remote, is taken. Instead the actions that would be taken if this flag was not set are printed to the logno
initialVersionThe default version to use when no previous version can be inferred from the commit history (i.e. when the repository has no tagged releases yet)no
presetThis option allows you to import one preset configuration into your configuration to save configuration time and effortno
releaseLenientWhen this option is enabled (it is by default), Nyx will attempt to tolerate prefixes and other unnecessary characters (like leading zeroes) when **reading** Git tags from the commit history. When true, tags like 'vx.y.x', 'relx.y.x' etc will be detected as release tags (for version 'x.y.x'), regardless of the prefix Nyx uses to generate release namesno
releasePrefixIt is a common practice to add a leading string to version numbers to give releases a name. Common prefixes are 'v' or 'rel' but you can use anything, or no prefix at allno
releaseTypesEnabledThe comma separated list of release types that are enabled for the project. Here you can enable or disable the various release types, either custom or default. The list of available release types is defined by the configured preset or a configuration fileno
releaseTypesPublicationServicesThe comma separated list of service configuration names to be used to publish releases when the matched release type has the publish flag enabled. The list of available services is defined by the configured preset or a configuration fileno
releaseTypesRemoteRepositoriesThe comma separated list of remote repository names to be used to push changes to when the matched release type has the gitPush flag enabled. The list of available remote repositories is defined by the configured preset or a configuration fileno
resumeWhen this flag is set to true Nyx tries to load an existing state file and resume operations from where it left when the state file was savedno
schemeSelects the version scheme to use. Defaults to 'SEMVER'no
sharedConfigurationFileThis option allows you to load a shared configuration file from a location other than default onesno
stateFileEnables the creation of the state file where Nyx stores its findings and generated valuesno
summaryFileEnables the creation of the summary file where Nyx saves a subset of relevant information from the internal state as name value pairs, easy to parseno
verbosityControls the amount of output emitted by Nyx, where values are: 'FATAL', 'ERROR', 'WARNING', 'INFO', 'DEBUG', 'TRACE'noINFO
versionOverrides the version and prevents Nyx to infer. When overriding this value you take over the tool and go the manual versioning way so Nyx will not try to read past versions from the commit history nor determine which identifiers to bumpno
namedescription
branchThis string contains the current Git branch name
bumpThis string contains the name of the identifier that has been bumped to create the new version. Version identifiers depend on the selected version scheme
coreVersionThis value is true when the version only uses core identifiers (i.e. is not a pre-release) according to the scheme
latestVersionThis value is true when the version is the latest in the repository, meaning that, according to the scheme, there are no other tags in the Git repository representing any version greater than 'version'
newReleaseThis value is true when the 'newVersion' is true and a new release with the current version has to be issued
newVersionThis value is true when the version is new and is basically a shorthand to testing if 'version' is different than the 'previousVersion'
schemeThe configured version scheme
timestampThe timestamp in the Unix format (seconds since 'Jan 01 1970. (UTC)'. Example: '1591802533'
previousVersionThe version that was released before the one being created
primeVersionThe version that is used as the baseline when bumping version numbers when the release type uses collapsed versioning (the pre-release versioning)
versionThe version that was inferred, unless the 'version' configuration option was passed to override inference. When the 'version' is not overridden or inferred the 'initialVersion' is used