| semver-mode | Controls how semantic version bumps are determined from commit messages.
Valid options: "conventional-commits" (default) or "keywords".
"conventional-commits" (default): Parses commit messages using the Conventional Commits specification (https://www.conventionalcommits.org/). Version bumps are determined by commit type and breaking change indicators:
- MAJOR: "BREAKING CHANGE" footer or "!" after type/scope (e.g., "feat!: drop Node 16")
- MINOR: "feat" type (e.g., "feat: add new endpoint")
- PATCH: "fix" type (e.g., "fix: resolve null pointer")
- Any other valid conventional commit type defaults to PATCH
The default-semver-level input is still respected as the fallback when a commit does not conform to the Conventional Commits format (i.e., has no recognized type prefix).
"keywords": Uses major-keywords, minor-keywords, and patch-keywords for simple substring matching against commit messages. This is the legacy behavior from versions prior to v1.9.0. When using this mode, the keyword-based inputs control version bumps.
| yes | conventional-commits |
| major-keywords | Keywords in commit messages that indicate a major release. Only used when semver-mode is "keywords". | yes | major change,breaking change |
| minor-keywords | Keywords in commit messages that indicate a minor release. Only used when semver-mode is "keywords". | yes | feat,feature |
| patch-keywords | Keywords in commit messages that indicate a patch release. Only used when semver-mode is "keywords". By default, everything will be a patch release if major or minor keywords are not found.
| yes | fix,chore,docs |
| default-semver-level | The default semantic version level to use when no semver rules match in the active semver-mode. In "conventional-commits" mode, this is the fallback when a commit does not conform to the Conventional Commits format (i.e., has no recognized type prefix). In "keywords" mode, this applies when NO commits match any configured keywords (major, minor, or patch).
If any commit triggers a version bump via the active mode's rules, that level takes precedence over this default.
Valid values: patch, minor, major
Example: With default-semver-level set to 'minor', non-matching commits will trigger a minor release. However, if any commit triggers a higher bump (e.g., 'feat!' → major), the higher level takes precedence.
| yes | patch |
| default-first-tag | Specifies the default tag version. (Should be in format v#.#.#) | yes | v1.0.0 |
| terraform-docs-version | Specifies the terraform-docs version used to generate documentation for the wiki.
See: https://github.com/terraform-docs/terraform-docs/releases
| yes | v0.21.0 |
| delete-legacy-tags | Specifies a boolean that determines whether tags from Terraform modules that have been deleted should be automatically removed. By default this is true as the purpose of the repository is to keep releases/tags clean. When removing a module, this will ensure the tags/releases are automatically cleaned.
| yes | true |
| disable-wiki | Whether to disable wiki generation for Terraform modules. By default, this is set to false. Set to true to prevent wiki documentation from being generated.
| yes | false |
| wiki-sidebar-changelog-max | An integer that specifies how many changelog entries are displayed in the sidebar per module. Adjust this value to control the visibility of changelog entries in the module sidebar.
| yes | 5 |
| wiki-usage-template | A raw, multi-line string to override the default 'Usage' section in the generated wiki. If not provided, a default usage block will be generated. | no | To use this module in your Terraform, refer to the below module example:
```hcl
module "{{module_name_terraform}}" {
source = "{{module_source}}?ref={{ref}}"{{ref_comment}}
# See inputs below for additional required parameters
}
```
|
| disable-branding | Flag to control whether the small branding link should be disabled or not in the pull request (PR) comments. When branding is enabled, a link to the action's repository is added at the bottom of comments. Setting this flag to "true" will remove that link. Useful for cleaner PR comments in enterprise environments or where third-party branding is undesirable.
| yes | false |
| module-path-ignore | A comma-separated list of module paths to completely ignore during processing. Paths matching these patterns will not be considered for versioning, releases, or documentation generation. These patterns follow glob syntax and are relative to the repository root. Use this to exclude example modules, test modules, or other paths that should not be treated as releasable modules.
This is a top-level filter: if a module matches any of these patterns, it is completely excluded from all release, versioning, and documentation logic. No releases will ever happen for a module that matches this filter.
The minimatch syntax is used for pattern matching. Patterns are relative to the workspace directory (no leading slash).
NOTE: To match both a directory and its contents, use separate patterns (e.g., "dir,dir/**").
| no | "" |
| module-change-exclude-patterns | A comma-separated list of file patterns to exclude from triggering version changes in Terraform modules. These patterns follow glob syntax and are relative to each Terraform module directory, not the repository root. Files matching these patterns will be tracked in the module but changes to them won't trigger a new version. Uses matchBase: true for pattern matching, so patterns like "*.md" will match files in any subdirectory.
This option allows you to release a module but control which files inside a matched Terraform module should not force a bump of the module version. For example, you may want to exclude documentation or test files from triggering a release, but still include them in the module asset bundle.
WARNING: Avoid excluding '*.tf' files, as they are essential for module functionality and versioning.
| yes | .gitignore,*.md,*.tftest.hcl,tests/** |
| module-asset-exclude-patterns | A comma-separated list of file patterns to exclude when bundling a Terraform module for release assets. These patterns follow glob syntax and are relative to each Terraform module directory, not the repository root. Files matching these patterns will be excluded from the bundled release archives. Uses matchBase: true for pattern matching, similar to module-change-exclude-patterns.
These patterns only affect what's included in release assets and do not impact versioning decisions.
| yes | .gitignore,*.md,*.tftest.hcl,tests/** |
| use-ssh-source-format | If enabled, all links to source code in generated Wiki documentation will use SSH format instead of HTTPS format.
| yes | false |
| github_token | Required for retrieving pull request metadata, tags, releases, updating PR comments, wiki, and creating tags/releases. Automatically injected for convenience; no need to provide a custom token unless you have specific requirements.
| yes | ${{ github.token }} |
| tag-directory-separator | Character used to separate directory path components in Git tags. This separator is used to convert module directory paths into tag names (e.g., 'modules/aws/s3-bucket' becomes 'modules-aws-s3-bucket-v1.0.0' when using '-'). Must be a single character from: /, -, _, or .
Examples with different separators: - "/" (default): modules/aws/s3-bucket/v1.0.0 - "-": modules-aws-s3-bucket-v1.0.0 - "_": modules_aws_s3_bucket_v1.0.0 - ".": modules.aws.s3.bucket.v1.0.0
| yes | / |
| use-version-prefix | Whether to include the 'v' prefix on version tags (e.g., v1.2.3 vs 1.2.3). When enabled, all new version tags will include the 'v' prefix. For initial releases, this setting takes precedence over any 'v' prefix specified in the default-first-tag - if use-version-prefix is false and default-first-tag contains 'v', the 'v' will be automatically removed to ensure consistency.
| yes | true |
| module-ref-mode | Controls how Terraform module usage examples reference versions in generated documentation. Valid values: "tag" or "sha". When "tag" (default), examples use the tag name in the ref parameter (e.g., ?ref=aws/vpc-endpoint/v1.1.3). When "sha", examples use the commit SHA with the tag as a comment (e.g., ?ref=abc123def456 # aws/vpc-endpoint/v1.1.3). This allows pinning to immutable commit SHAs that cannot be deleted, useful with Renovate for handling module removal scenarios. Note: This only affects generated documentation; tag and release creation remains unchanged.
| yes | tag |
| pre-release | Whether to mark created GitHub releases as pre-releases. When true, releases will be flagged as pre-releases on GitHub, which excludes them from being considered the "latest" release. This is useful in monorepos where per-module releases may conflict with other release tooling (e.g., auto shipit) that determines the latest release via the GitHub API.
| yes | false |
| hide-no-changes-pr-comment | Whether to suppress the "Release Plan" pull request comment when the pull request has nothing to report. A pull request has "nothing to report" when it changes no Terraform modules, has no pending tag/release cleanup (when delete-legacy-tags is enabled), and the wiki check did not fail. By default this is false, preserving the existing behavior where a "Release Plan" comment is always posted on every open pull request run.
When set to true and a pull request has nothing to report:
- If no Release Plan comment exists yet, none is created (and therefore no email notification
is sent).
- If a Release Plan comment already exists (e.g. an earlier push had changes that were later
removed), it is updated in place and minimized/collapsed. Because this is an edit to an
existing comment, GitHub does not send a new email notification.
When the pull request does have changes, the Release Plan comment is posted exactly as before (recreated at the bottom of the timeline to signal a fresh run). This setting only affects the open-pull-request Release Plan comment; the post-merge release comment is unaffected.
| yes | false |