GitOps.Config (Git Ops v2.12.1)
View SourceHelpers around fetching configurations, including setting defaults.
Configuration is resolved from a git_ops.json file at the repository root
when one exists, falling back to the application environment otherwise. The
file form is required for multi-package (monorepo) repositories and supports
releasing projects that have no mix project at all.
Summary
Functions
Whether to close the open release pull request for a package that no longer
has releasable changes. Defaults to false.
The path of the JSON config file, relative to the repository root.
Whether commit collection follows only the first parent of merges.
Returns the base URL for the GitHub API. Override this if you are using a self-hosted GitHub instance.
Returns whether GitHub integrations are enabled.
Groups of package paths whose versions move in lockstep: when any package in a group releases, every package in that group releases at that version.
The packages this repository releases.
Labels applied to release pull requests when they are created.
How releases are performed.
The order changelog sections appear in. Types not listed sort after the listed ones, alphabetically.
The pattern a version-bump commit must match for mix git_ops.tag_merged
to tag it. Guards against a stray version-file edit in an ordinary commit
becoming a release.
Where the current version is read from.
Functions
Whether to close the open release pull request for a package that no longer
has releasable changes. Defaults to false.
The path of the JSON config file, relative to the repository root.
When the file exists it takes precedence over the application environment.
Whether commit collection follows only the first parent of merges.
Returns the base URL for the GitHub API. Override this if you are using a self-hosted GitHub instance.
Returns whether GitHub integrations are enabled.
When enabled, the system will attempt to find GitHub usernames for commit authors and pull request information. When disabled or if lookup fails, it will use the author's name directly.
Groups of package paths whose versions move in lockstep: when any package in a group releases, every package in that group releases at that version.
The packages this repository releases.
A packages map in the config file produces one entry per package.
Otherwise there is a single package rooted at the repository, configured
from the file's top level or from the application environment.
Labels applied to release pull requests when they are created.
How releases are performed.
:commit(default) - commit and tag directly on the current branch.:pull_request- push a release branch and open a pull request; tags are created after the pull request merges, bymix git_ops.tag_merged.
The order changelog sections appear in. Types not listed sort after the listed ones, alphabetically.
The pattern a version-bump commit must match for mix git_ops.tag_merged
to tag it. Guards against a stray version-file edit in an ordinary commit
becoming a release.
Where the current version is read from.
:mix(default) - the configuredmix_project's:version.:tags- the last valid version tag (respectingversion_tag_prefix), making tags the source of record. Requires no mix project, so this enables releasing non-Elixir projects.{:file, path, regex}- the first capture group ofregexrun against the contents ofpath.