GitOps.Config (Git Ops v2.11.2)

View Source

Helpers 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

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

allow_untagged?()

allowed_tags()

changelog_file()

config_file()

The path of the JSON config file, relative to the repository root.

When the file exists it takes precedence over the application environment.

first_parent?()

Whether commit collection follows only the first parent of merges.

github_api_base_url()

Returns the base URL for the GitHub API. Override this if you are using a self-hosted GitHub instance.

github_handle_lookup?()

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.

linked_packages()

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.

manage_mix_version?()

manage_readme_version()

managed_files()

mix_project()

mix_project_check(opts \\ [])

packages()

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.

pr_labels()

Labels applied to release pull requests when they are created.

prefix()

release_strategy()

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, by mix git_ops.tag_merged.

repository_path()

repository_url()

section_order()

The order changelog sections appear in. Types not listed sort after the listed ones, alphabetically.

tag_merged_commit_pattern()

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.

type_keys()

types()

version_source()

Where the current version is read from.

  • :mix (default) - the configured mix_project's :version.
  • :tags - the last valid version tag (respecting version_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 of regex run against the contents of path.