I currently have a system that I can manually create a pre-release and then grab the artifacts based on the git commit, but for more stable builds, I'd like to have a workflow that is as follows:

• User creates tag / release draft. This triggers Actions workflow
• Run linting & testing (rustfmt, cargo check and cargo clippy) to make sure everything is fine before building
• Build binaries for Windows, Mac, and Linux
• Upload each binary to the release
• Publish the release

Other Solutions

On top of this, I could look into tools like Covector to automate the release process to a point. Not set in stone with anything yet but it could be useful to build some system for publishing rust binaries so I can use it on other applications I build in the future.

As well, this may be useful for libraries as well of instead of building binaries I can create a semi-automated cargo publish workflow for releases of any crates I decide to develop.

Apple Silicon builds (cargo target aarch64-apple-darwin) seems to require MacOS Big Sur which is only available at the moment as a private preview on GitHub Actions, so until then I will not be able to build Apple Silicon builds in CI until that is opened to the public.

That said, once things are resolved there, I may ship a universal binary for MacOS so you can download one binary and it can work on both Intel and Apple Silicon Macs.

Currently I have color-eyre for errors, but I would like to add further logging for the CLI. Possibility is using the tracing crate from the Tokio project

This can be another location to source the deploy dir, functions, etc.

The netlify-toml crate already has functionality to parse the toml file into a Rust struct so it would be useful for this.

Look into adding https://crates.io/crates/indicatif to show visual progress for longer uploads

When uploading as part of a non-production build, it would be helpful to somehow return the url of the preview that is created. That url can then be included as a comment on a PR. This makes it easier to review dependency updates that are opened through a bot.

Take large Netlify sites (100 files, 1k files, 10k files) and benchmark this CLI against the JS CLI to compare how each performs.

For large sites, listing out the files & hashes to be deployed is going to be taxing and probably isn't necessary to use so I will want to remove the various dbg! / println! calls I currently have in the program.

I've modified the program pretty substantially but I'm pretty sure the issue is present in the version in this repo.

The hashes BiMap is unique for both the right and left values; if two files have the same contents the second will overwrite the first because the hashes (right value in the bimap) are the same. The list of files sent to netlify is then generated from hashes and thus won't include multiple files with the same content.

Add the ability for a flag / env variable to change the draft field in the CreateDeployArgs struct so not every deploy is to production

Upload the functions folder as part of a deploy. I will have to see how to do this in Rust given the JS CLI uses zip-it-and-ship-it to zip up and get a sha1 hash for each function.