committed
cargo-release
committed | cargo-release | |
---|---|---|
5 | 11 | |
94 | 1,245 | |
- | 1.3% | |
7.9 | 9.1 | |
3 days ago | 4 days ago | |
Rust | Rust | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
committed
-
Any good alternative to husky in rust to enforce and write conventional commits and for pre-commit source code linting??
I use https://github.com/crate-ci/committed and pre-commit (the python app)
-
[Gitoxide December Update]: a new object database and upcoming multi-pack index support
committed just reads commit messages between a range of commits, after resolving refs
-
Ouch 0.3.0 released!
For colors, I've found yansi to be great to work with. I then use concolor-control (example) and `concolor-clap (no clap3 support yet, example part 1 and example part 2). As you can see, I also like to organize my colors by the styling role they fill. The only reason I wrapped in that example is its part of the crate's API and didn't want the public API tied to yansi.
-
Git-cliff: generate changelog files from the Git history
While auto-generated changelogs aren't the best, they are better than nothing. Too often I've seen projects without a changelog which is especially annoying when dealing with breaking changes.
I've been considering switching to a changelog generator, either from Conventional Commits or from a folder of files just to avoid merge conflicts with the CHANGELOG file.
If people want enforcement of Conventional Commit, check out https://github.com/crate-ci/committed
- Committed – A commit message linter optionally supporting conventional commits
cargo-release
-
Changelog-Driven Releases
My problem with maintaining a changelog during development is it can serve as a source of merge conflicts. Instead, I follow Covnentional Commit style and manually write my changelog entries based on the commits. I have a tool [0] that can show me the relevant commits for a package in my repo and automates the entire release process, including doing sanity checks.
I also feel like releasing from CI is hard, especially if you have multiple packages in a repo [1], including
- You can't as easily introspect the process
- You can't as easily recover from failure
- Getting a lot of the nuance right, like handling releases concurrent to merging of PRs, is difficult
- When the workflow is an ever-present "release PR" that you merge when ready has issues with selecting which packages to release and at what version
I have been considering making a tool to generate changelogs from fragments. Been keeping notes at https://github.com/epage/epage.github.io/issues/23
[0]: https://github.com/crate-ci/cargo-release
[1]: https://github.com/MarcoIeni/release-plz/discussions/1019
-
Oxlint – written in Rust – 50-100 Times Faster than ESLint
You should combine step 1 and 2 with CI. Just tag a version in your git, push to remote and have CI auto build a release for you.
Use github actions or other setup for other backends.
Or go nuts with cargo-release.
https://github.com/crate-ci/cargo-release
https://github.com/cargo-bins/release-pr
-
Rust 2030 Christmas list: Subcrate dependencies
tools like cargo-release
-
`toml` vs `toml_edit` (ie `toml` 0.6 is out)
Just to check, are you aware of cargo-edit's cargo-set-version or cargo-release?
-
What's everyone working on this week (45/2022)?
I released my first crate that provides a derive macro to easily obtain a name of a current variant in an enum as a string. I did it mostly to learn about procedural macros and the process of releasing a crate. I then found out there is strum which does this and much more. Nonetheless, I learned a lot and I found couple of nice tools like ```cargo-release and git-cliff.
- cargo-release v0.22 is out!
-
A GitHub Action for creating "Release PRs" for Cargo projects.
I'll note there is an issue in the cargo-release repo where this kind of workflow is wanted. https://github.com/crate-ci/cargo-release/issues/119
-
[Gitoxide December Update]: a new object database and upcoming multi-pack index support
cargo-release is on about the same level of features used
-
cargo-release v0.19
cargo-release automates the release process for your crate. For example, with clap, all I do is add entries to the CHANGELOG and run cargo release patch and cargo-release takes care of updating files, publishing to crates.io, tagging, and pushing.
-
Introducing `cargo smart-release` - the new way to release workspace crates
Yes, developers from all three tools were sharing ideas with each other recently
What are some alternatives?
auto-changelog-action
Rustup - The Rust toolchain installer
onefetch - Command-line Git information tool
just - 🤖 Just a command runner
gitoxide - An idiomatic, lean, fast & safe pure Rust implementation of Git
cargo-make - Rust task runner and build tool.
git-hooks.nix - Seamless integration of https://pre-commit.com git hooks with Nix.
Clippy - A bunch of lints to catch common mistakes and improve your Rust code. Book: https://doc.rust-lang.org/clippy/
GitHub Changelog Generator - Automatically generate change log from your tags, issues, labels and pull requests on GitHub.
cargo-ebuild - cargo extension that can generate ebuilds using the in-tree eclasses
gnulib - upstream mirror
cargo-modules - Visualize/analyze a Rust crate's internal structure