4 ms·
The "way-too-quickstart" is the minimal example: https://github.com/axodotdev/cargo-dist#way-too-quick-start https://github.com/axodotdev/cargo-dist#way-too-qui
by Gankra 4y ago
The "way-too-quickstart" is the minimal example: https://github.com/axodotdev/cargo-dist#way-too-quick-start 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.
- Gankra 4y agoJust 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 https://github.com/axodotdev/cargo-dist/#concepts [1]: https://github.com/axodotdev/cargo-dist/issues/69 https://github.com/axodotdev/cargo-dist/issues/69
- MuffinFlavored 4y agoCool, 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.