Hacker News Reader

Comment by MuffinFlavored | Hacker News Reader

I think this would benefit from an example repo that shows just Cargo.toml for a simple src/main.rs with `fn main() { println!("Hello, world!"); }` project with the simplest needed .github/workflows/foo.yaml possible to actually use this.

If it was in the article and I missed it I apologize.

View on HN

The "way-too-quickstart" is the minimal example: https://github.com/axodotdev/cargo-dist#way-too-quick-start

A key feature of cargo-dist is that

cargo dist init --ci=github

should simply set everything up for an arbitrary* Rust workspace and you just check in the results.

* Not sufficiently tested for all the wild workspaces you can build, but a "boring" one with a bunch of libraries supporting one binary should work -- that's what cargo-dist's own workspace is, and it's self-hosting without any configuration. Any time I want to update the bootstrap dist I just install that version of cargo-dist on my machine and run `cargo dist generate-ci github --installer=...` to completely overwrite the ci with the latest impl.

Just to elaborate on this a bit: as discussed in the Concepts section of the docs[0] the core of cargo-dist absolutely supports workspaces with multiple binaries, and will chunk them out into their own distinct logical applications and provide builds/metadata for all them.

However this isn't fully supported by the actual github CI integration yet[1], as I haven't implemented proper support for detecting that you're only trying to publish a new version of only one of the applications (or none of them!), and it doesn't properly merge the release notes if you're trying to publish multiple ones at once.

I never build workspaces like that so I'm waiting for someone who does to chime in with the behaviour they want (since there's lots of defensible choices and I only have so many waking hours to implement stuff).

[0]: https://github.com/axodotdev/cargo-dist/#concepts [1]: https://github.com/axodotdev/cargo-dist/issues/69

Cool, thanks.

It creates a ~100 line release.yml file

1. create GitHub release

2. upload artifacts

3. upload manifest

4. publish GitHub release

I like it, it's opinionated, but I don't know how much it will catch on. If somebody needs to maintain a 100 line GitHub Actions release YAML file, in my experience you typically want to understand everything in it in case you need to adjust it for future needs/as they grow.

It's well done though. Curious to see how much adoption it picks up.

Reply on news.ycombinator.com