ci: use standard-version to generate new version from conventional commits #33
Conversation
Cargo.lock
Outdated
There was a problem hiding this comment.
This diff arose due to running cargo update, which I ran while experimenting with publishing a crate. While not strictly related to this PR, it's worth keeping.
| @@ -1,7 +1,7 @@ | |||
| [package] | |||
| name = "tree-sitter-gitcommit" | |||
| description = "gitcommit grammar for the tree-sitter parsing library" | |||
| version = "0.0.1" | |||
| version = "0.2.0" | |||
There was a problem hiding this comment.
I had to manually bump this version to match the version in package.json. scripts/update-cargo-version.js will handle version bumps.
| @@ -0,0 +1,31 @@ | |||
| /// @ts-check | |||
|
|
|||
| const versionPattern = /[ \t]*version\s*=\s*"([^"]+)"/; | |||
There was a problem hiding this comment.
Using a regex is faster and easier to understand than parsing and patching the entire abstract syntax tree of the Cargo.toml document.
SKalt
changed the title
SKalt
force-pushed
the
automate-npm-and-cargo-releases
branch
2 times, most recently
from
d3e6b14 to
a173d77
Compare
This commit adds a local workflow for creating a git tag for a release. Here's the proposed workflow: `npm run prepare-release` will run `standard-version`. `standard-version` bumps the versions in `package.json` and `Cargo.toml` and adds an autogenerated entry to `CHANGELOG.md`, then commits those changes and tags them with the new version. You can safely test this workflow locally. This tooling augments the new github workflows for gbprod#30: you can associate a new release with the generated tags, or you could trigger the package-publishing workflows ```yaml on: push: tags: - 'v*.*.*' ```
SKalt
force-pushed
the
automate-npm-and-cargo-releases
branch
from
a173d77 to
5ff5a6e
Compare
|
Thanks for your PR! |
gbprod
force-pushed
the
main
branch
4 times, most recently
from
9093562 to
adf879c
Compare
|
Hi @SKalt !
|
This PR adds a local workflow for creating a git tag for a release. Here's the proposed workflow:
npm run prepare-releasewill runstandard-version.standard-versionbumps the versions inpackage.jsonandCargo.tomland adds an autogenerated entry toCHANGELOG.md, then commits those changes and tags them with the new version. You can safely test this workflow locally.This tooling augments the new github workflows for #30 : you can associate a new release with the generated tags, or you could trigger the package-publishing workflows