Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
chore(deps): update dependency knope to 0.18.0 (#1189)
This PR contains the following updates: | Package | Update | Change | |---|---|---| | [knope](https://knope.tech) ([source](https://redirect.github.com/knope-dev/knope)) | minor | `0.11.0` -> `0.18.0` | | [knope](https://knope.tech) ([source](https://redirect.github.com/knope-dev/knope)) | minor | `0.13.0` -> `0.18.0` | | [knope](https://knope.tech) ([source](https://redirect.github.com/knope-dev/knope)) | minor | `0.7.4` -> `0.18.0` | --- ### Release Notes <details> <summary>knope-dev/knope (knope)</summary> ### [`v0.18.0`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0180-2024-08-18) ##### Breaking Changes ##### Auto-update Cargo workspace dependencies when using default config If using the Cargo workspace [default configuration](https://knope.tech/reference/default-config/#cargo-workspaces), Knope will now attempt to automatically update the version of workspace members in dependencies *and* the workspace `Cargo.lock`. To avoid this, use `knope --generate` to create a manual config file and customize the behavior. ##### Don't create *any* go module tags that match package names Knope already avoided creating duplicate tags for Go modules which match tags that would be created by the `Release` step for the package. Now, Knope won't create a Go module tag if it matches a release tag for *any* configured package, to avoid potential conflicts. ##### Features ##### Support for `Cargo.lock` in `versioned_files` Dependencies within a `Cargo.lock` [can now be updated](https://knope.tech/reference/config-file/packages#cargolock). ##### Support for dependencies within `Cargo.toml` Dependencies within a `Cargo.toml` file [can now be updated](https://knope.tech/reference/config-file/packages/) as part of `versioned_files`. ##### Fixes ##### Deduplicate release actions Knope now collects all actions to be performed across all packages and runs them at once with deduplication. This means that if multiple packages write to the same `versioned_file`, for example, the file will only be written a single time. Changesets will also only be deleted once, files will be staged to Git only once, etc. This mostly only impacts the output during `--dry-run` or `--verbose`, but is especially important for the new dependency updating and lockfile support. ### [`v0.17.0`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0170-2024-08-04) ##### Breaking Changes ##### Forge date now matches CHANGELOG date If you prepare a release and generate a changelog Markdown file in one workflow, then create a forge release in a separate workflow, the forge release date will now match the changelog date (if any). Previously, the forge release got the current date (at the time of running the workflow). ##### Match scope-filtering behavior to docs The docs state, in regard to a `package.scopes` config, "if not defined, Knope will consider all scopes." This is the intended behavior, but wasn't true until now. The actual behavior, for multi-package repos, was that if *any* package had scopes defined, *all* would start filtering scopes. This has been corrected, packages are now more independent in their scope filtering behavior. ##### Properly use case insensitivity when checking conventional commits Per the [conventional commits spec](https://www.conventionalcommits.org/en/v1.0.0/#specification) all units of a conventional commit are case-insensitive. Until now, Knope was treating commit footers and scopes as case-sensitive. This has been corrected, which may result in different behavior for some projects. ### [`v0.16.2`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0162-2024-04-14) ##### Features ##### Add `get-version` default workflow For **single-package repositories** with no custom workflows defined, there is now a [default workflow](https://knope.tech/reference/default-config/#workflows) called `get-version` that prints out the current package version. If you want similar functionality for multi-package repositories, please add your ideas to [issue #​988](https://redirect.github.com/knope-dev/knope/issues/988). Thanks to [@​BatmanAoD](https://redirect.github.com/BatmanAoD) for the suggestion and [@​alex-way](https://redirect.github.com/alex-way) for the implementation! PR [#​994](https://redirect.github.com/knope-dev/knope/issues/994) closed [#​885](https://redirect.github.com/knope-dev/knope/issues/885). ##### Add option to ignore conventional commits You can now add `ignore_conventional_commits = true` to a [`PrepareRelease` step](https://knope.tech/reference/config-file/steps/prepare-release/) to ignore commit messages (and only consider changesets): ```toml [[workflows.steps]] type = "PrepareRelease" ignore_conventional_commits = true ``` PR [#​1008](https://redirect.github.com/knope-dev/knope/issues/1008) closes [#​924](https://redirect.github.com/knope-dev/knope/issues/924). Thanks for the suggestion [@​ematipico](https://redirect.github.com/ematipico)! ##### Fixes - Allow omitting the `variables` field for `CreatePullRequest` title and body ##### Documentation ##### Created a new recipe for converting a single-package repo into a monorepo Knope itself is now a monorepo—the process of converting it was documented [here](https:/knope.tech/recipes/convert-to-monorepo). ### [`v0.16.1`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0161-2024-03-24) [Compare Source](https://redirect.github.com/knope-dev/knope/compare/v0.16.0...v0.16.1) ##### Features ##### Add `help_text` option to workflows `[[workflows]]` can now have `help_text`: Example: ```toml [[workflows]] name = "release" help_text = "Prepare a release" ``` The message is displayed when running `knope --help`: ```text A command line tool for automating common development tasks Usage: knope [OPTIONS] [COMMAND] Commands: release Prepare a release help Print this message or the help of the given subcommand(s) ... ``` PR [#​960](https://redirect.github.com/knope-dev/knope/issues/960) closes issue [#​959](https://redirect.github.com/knope-dev/knope/issues/959). Thanks [@​alex-way](https://redirect.github.com/alex-way)! ##### Use bullets to describe simple changes The previous changelog & forge release format used headers for the summary of all changes, these entries were hard to follow for simple changes like this: ```markdown ##### Features ##### A feature ##### Another header with no content in between? ``` Now, *simple* changes are described with bullets at the *top* of the section. More complex changes will come after any bullets, using the previous format: ```markdown ##### Features - A simple feature - Another simple feature ##### A complex feature Some details about that feature ``` Right now, a simple change is any change which comes from a conventional commit (whether from the commit summary or from a footer) *or* a changeset with only a header in it. Here are three simple changes: feat: A simple feature Changelog-Note: A note entry ### [`v0.16.0`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0160-2024-03-20) [Compare Source](https://redirect.github.com/knope-dev/knope/compare/v0.15.0...v0.16.0) ##### Breaking Changes ##### Don't delete changesets for prereleases Previously, using `PrepareRelease` to create a prerelease (for example, with `--prerelease-label`) would delete all changesets, just like a full release. This was a bug, but the fix is a breaking change if you were relying on that behavior. ##### Features ##### Add a `shell` variable for `Command` steps You can now add `shell=true` to a `Command` step to run the command in the current shell. This lets you opt in to the pre-0.15.0 behavior. ```toml [[workflows.steps]] type = "Command" command = "echo $AN_ENV_VAR" shell = true ``` ### [`v0.15.0`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0150-2024-03-18) [Compare Source](https://redirect.github.com/knope-dev/knope/compare/v0.14.1...v0.15.0) ##### Breaking Changes ##### Don't run `Command` steps in shell The `Command` step no longer attempts to run the command in a default shell for the detected operating system. This fixes a compatibility issue with Windows. If this change doesn't work for your workflow, please open an issue describing your need so we can fix it. Notably, using `&&` in a command (as was the case for some default workflows) will no longer work. Instead, split this into multiple `Command` steps. PR [#​919](https://redirect.github.com/knope-dev/knope/issues/919) closes issue [#​918](https://redirect.github.com/knope-dev/knope/issues/918). Thanks for reporting [@​alex-way](https://redirect.github.com/alex-way)! ### [`v0.14.1`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0141-2024-02-23) [Compare Source](https://redirect.github.com/knope-dev/knope/compare/v0.14.0...v0.14.1) ##### Features ##### Add `ignore_go_major_versioning` option You can now set `ignore_go_major_versioning = true` for a package in `knope.toml` to turn off the major version validation & updating in `go.mod` files. More details in [the new docs](https://knope.tech/reference/config-file/packages/#ignore_go_major_versioning). Closes [#​863](https://redirect.github.com/knope-dev/knope/issues/863), thanks for the suggestion [@​BatmanAoD](https://redirect.github.com/BatmanAoD)! ### [`v0.14.0`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0140-2024-02-04) [Compare Source](https://redirect.github.com/knope-dev/knope/compare/v0.13.4...v0.14.0) ##### Breaking Changes ##### `Cargo.toml` files must now have a `package.name` property This was already required by Cargo, but wasn't enforced by Knope until now. Before, a `Cargo.toml` file like ```toml [package] version = "0.1.0" ``` was acceptable, but now it must be ```toml [package] name = "my-package" version = "0.1.0" ``` ##### Features ##### Add basic Cargo workspace support If you have a `Cargo.toml` file in the working directory which represents a Cargo workspace containing fixed members, like: ```toml [workspace] members = [ "my-package", "my-other-package", ] ``` then Knope will now treat each member like a package. There must be a `Cargo.toml` file in each member directory, or Knope will error. This doesn't work with path globbing yet, only manual directory entries. See [the new docs](https://knope.tech/reference/default-config/#cargo-workspaces) for more details. ##### Use default packages/workflows even when `knope.toml` exists If you define a `knope.toml` file without any packages, Knope will assume the default packages (as if you had no `knope.toml` file at all). Likewise, if you have no `[[workflows]]` in a `knope.toml` file, Knope will assume the default workflows. ##### Fixes ##### Homebrew tap now contains Apple Silicon binaries and auto-publishes new versions ([#​827](https://redirect.github.com/knope-dev/knope/issues/827)) ### [`v0.13.4`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0134-2024-01-13) [Compare Source](https://redirect.github.com/knope-dev/knope/compare/v0.13.3...v0.13.4) ##### Features ##### Gitea support PR [#​759](https://redirect.github.com/knope-dev/knope/issues/759) closed issue [#​743](https://redirect.github.com/knope-dev/knope/issues/743). Thank you, [@​FallenValkyrie](https://redirect.github.com/FallenValkyrie)! - Added Support for Gitea in the `CreatePullRequest` step - Added Support for Gitea in the `Release` step - Added A new `SelectGiteaIssue` step - Add support to generate Gitea config from known public Gitea instances To use these new steps, just add a new section to your configuration, like this: ```toml [gitea] repo = "knope" owner = "knope-dev" host = "https://codeberg.org" ``` You can now use the supported steps in the same way as their GitHub equivalents. > \[!TIP] > Knope can now generate a configuration for you, if your repository's remote is one of the known > public Gitea instances. Currently only [Codeberg](https://codeberg.org) is supported, > but feel free to add more [here](https://redirect.github.com/knope-dev/knope/blob/main/src/config/toml/config.rs#L90). ### [`v0.13.3`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0133-2023-12-17) [Compare Source](https://redirect.github.com/knope-dev/knope/compare/v0.13.2...v0.13.3) ##### Features ##### Support `pubspec.yaml` in `versioned_files` Knope can now version Dart projects! You can now add a `pubspec.yaml` file to your `package.versioned_files`. PR [#​732](https://redirect.github.com/knope-dev/knope/issues/732) closes [#​731](https://redirect.github.com/knope-dev/knope/issues/731). Thanks [@​FallenValkyrie](https://redirect.github.com/FallenValkyrie)! ### [`v0.13.2`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0132-2023-11-11) [Compare Source](https://redirect.github.com/knope-dev/knope/compare/v0.13.1...v0.13.2) ##### Fixes ##### Add `[github]` section with `knope --generate` ([#​666](https://redirect.github.com/knope-dev/knope/issues/666)) ##### `--dry-run` will no longer report deleting the same changeset twice ([#​668](https://redirect.github.com/knope-dev/knope/issues/668)) ##### `CreateChangeFile` (like `knope document-change`) now prints package names. ([#​669](https://redirect.github.com/knope-dev/knope/issues/669)) ### [`v0.13.1`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0131-2023-11-05) [Compare Source](https://redirect.github.com/knope-dev/knope/compare/v0.13.0...v0.13.1) ##### Documentation ##### There is a new docs website Check out <https://knope.tech/> to see the new docs, and please report any errors or gaps! All error messages within Knope should be updated to point to the new docs. If any are still pointed at GitHub pages (as of this version), that's a bug! As part of this, you can also now install Knope through [Chocolatey and Homebrew](https://knope.tech/installation)! ### [`v0.13.0`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0130-2023-10-22) [Compare Source](https://redirect.github.com/knope-dev/knope/compare/v0.12.0...v0.13.0) ##### Breaking Changes ##### Change changeset title level The level of the title of a changeset no longer impacts the level of the release header in the changelog. To make this more obvious, changeset title are now level one headers by default. This is a breaking change because older versions of Knope will no longer properly handle the changesets from newer versions of Knope. ##### Change where new versions are inserted in changelog In practice, this will not impact most changelogs, however, previous versions of Knope looked for the first header at a certain level (e.g., starting with ` ## `) and inserted the new version right before that. Now, Knope looks for the first header that is parseable as a semver version (e.g., `## 1.2.3`) and inserts the new version right before that. This *will* make it harder to adopt Knope in projects that have an existing changelog which is not of the same format, but it makes inserting the new version in the changelog more robust. ##### Features ##### Allow overriding built-in changelog sections If you don't want to use the default changelog sections of "Breaking changes", "Features", and "Fixes", you can now override them by using the equivalent changeset types! Overriding them resets their position in the changelog, so you probably want to reset *all* of them if you reset any. This looks like: ```toml [package] extra_changelog_sections = [ { type = "major", name = "❗️Breaking ❗" }, { type = "minor", name = "🚀 Features" }, { type = "patch", name = "🐛 Fixes" }, { footer = "Changelog-Note", name = "📝 Notes" }, ] ``` ##### Support level-one release headers in changelogs If the last release in a changelog file has a level-one header instead of Knope's default of level-two, new releases will be created with level-one headers as well. Sections will then be level two instead of level three. ### [`v0.12.0`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0120-2023-09-30) [Compare Source](https://redirect.github.com/knope-dev/knope/compare/v0.11.1...v0.12.0) ##### Breaking Changes ##### Prevent bumping major version of a `go.mod` file According to [the docs](https://go.dev/blog/v2-go-modules), 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](https://redirect.github.com/knope-dev/knope/issues/584) from [@​BatmanAoD](https://redirect.github.com/BatmanAoD). If you have a `go.mod` file representing a specific major version in a directory (as recommended in [the go docs](https://go.dev/blog/v2-go-modules)), 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`: ```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](https://knope.tech/reference/config-file/steps/release/). ### [`v0.11.1`](https://redirect.github.com/knope-dev/knope/blob/HEAD/CHANGELOG.md#0111-2023-09-22) [Compare Source](https://redirect.github.com/knope-dev/knope/compare/v0.11.0...v0.11.1) ##### 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: ```toml [[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" ``` [the `Command` step]: https://knope.tech/reference/config-file/steps/command/ ##### Added an `allow_empty` option to the `PrepareRelease` step Closes [#​416](https://redirect.github.com/knope-dev/knope/issues/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: ```toml [[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: ```yaml - 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]. [`CreatePullRequest` step]: https://knope.tech/reference/config-file/steps/create-pull-request/ [Knope's prepare-release workflow]: https://redirect.github.com/knope-dev/knope/blob/e7292fa746fe1d81b84e5848815c02a0d8fc6f95/.github/workflows/prepare_release.yml [knope's release workflow]: https://redirect.github.com/knope-dev/knope/blob/e7292fa746fe1d81b84e5848815c02a0d8fc6f95/.github/workflows/release.yml ##### 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](https://knope.tech/recipes/1-preview-releases-with-pull-requests/) with some recipes for using Knope in GitHub Actions. If you have suggestions for additional recipes, please open a [discussion](https://redirect.github.com/knope-dev/knope/discussions)! </details> --- ### 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 these updates again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/knope-dev/knope). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC43NC4xIiwidXBkYXRlZEluVmVyIjoiMzguNzQuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
- Loading branch information
1 parent
d24bd68
commit 30855f2