chore(deps): update dependency knope to v0.12.0

[renovate]

This PR contains the following updates:

Package	Update	Change
knope (source)	minor	0.11.0 -> 0.12.0

---

Release Notes

knope-dev/knope (knope)

v0.12.0

Compare Source

Breaking Changes

Prevent bumping major version of a go.mod file

According to the docs, aside from the v0 -> v1 transition, go.mod files should not be updated for new major versions, but instead a new v{major} directory should be created with a new go.mod file. This is for compatibility with older versions of Go tools.

In order to prevent someone from accidentally doing the wrong thing, Knope will no longer bump a go.mod file to v2 unless --override-version is used to bypass this check. Additionally, if a go.mod file is in the matching versioned directory (e.g., the go.mod file ending in /v2 is under a directory called v2), Knope will not allow the major version of that file to be bumped, as it would break the package.

Fixes

Handle version-specific go modules correctly

Fixes #​584 from @​BatmanAoD.

If you have a go.mod file representing a specific major version in a directory (as recommended in the go docs), Knope will now tag it correctly. Previously, a v2/go.mod file would generate a tag like v2/v2.1.3. Now, it will generate a tag like v2.1.3.

Additionally, when determining the current version for a go.mod file, only tags which match the major version of the go.mod file will be considered.

Properly version named packages containing a root go.mod file

Consider this package config in a knope.toml:

[packages.something]
versioned_files = ["go.mod"]

The Release step previously (and will still) add a tag like something/v1.2.3, however the correct Go module tag is v1.2.3 (without the package name prefix). Knope will now correctly add this second tag (previously, top-level tags were only added for single-package repos).

Documentation

Document conflict between package names and go module names

It is possible to write a knope.toml file which will cause conflicting tags during the Release step if you have go.mod files in nested directories. This is now documented.

v0.11.1

Compare Source

Features

Add a ChangelogEntry variable for substitution

Anywhere that the existing Version variable can be used (for example, in [the Command step][the Command step]), you can now also use ChangelogEntry to get the section of the changelog that corresponds to the current version. For example, you could (almost) replicate Knope's GitHub Release creation without Knope's GitHub integration with a workflow like this:

[[workflows]]
name = "release"

[[workflows.steps]]
type = "PrepareRelease"

[[workflows.steps]]
type = "Command"
command = "git commit -m \"chore: prepare release $version\" && git push"

[workflows.steps.variables]
"$version" = "Version"

[[workflows.steps]]
type = "Command"
command = "gh release create --title '$version' --notes '$changelog'"

[workflows.steps.variables]
"$version" = "Version"
"$changelog" = "ChangelogEntry"

Added an allow_empty option to the PrepareRelease step

Closes #​416

If you want to run PrepareRelease on every push to a branch without it failing when there's nothing to release, you can now include the allow_empty option like this:

[[workflows.steps]]
type = "PrepareRelease"
allow_empty = true

Then, you can use some logic to gracefully skip the rest of your CI process if there is nothing to release. For example, in GitHub Actions, you could do something like this:

- name: Prepare Release
  run: knope prepare-release
- name: Check for Release
  id: status
  run: echo ready=$(if [[ `git status --porcelain` ]]; then echo "true"; else echo "false"; fi;) >> $GITHUB_OUTPUT
- name: Release
  if: steps.status.outputs.ready == 'true'
  run: knope release

This allows you to differentiate between there being nothing to release and the PrepareRelease step failing for other reasons.

New CreatePullRequest step

The new [CreatePullRequest step][CreatePullRequest step] allows you to create or update a pull request on GitHub. It's designed to be a nice way to preview and accept new releases via a pull request workflow, but could certainly work for more contexts as well! To see an example of the new PR-based release workflow, check out Knope's prepare-release workflow and Knope's release workflow.

Fixes

Only consider prereleases newer than the last stable

This fixes a regression in the previous version of Knope where all prereleases would be considered, rather than just those tagged after the latest stable version.

Documentation

GitHub Actions Recipes

There's a new section of the docs with some recipes for using Knope in GitHub Actions. If you have suggestions for additional recipes, please open a discussion!

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.

[codecov]

Codecov Report

Merging #862 (2fc55dc) into main (6a01172) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main      #862   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           49        49           
  Lines         1920      1920           
=========================================
  Hits          1920      1920           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠ Warning: custom changes will be lost.