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.

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.

Version Updates

Merging this PR will bump all of the applicable packages based on your change files.

netlify_deploy

[0.3.0]

• The File I/O reads & HTTP requests are now running asynchronously on top of Tokio. This reduced a 2,000 file upload to Netlify down to ~1 minute.
  • 238b450 Switching sync tasks to run async on 2021-05-22

Helps with #6 by moving the std::fs calls to tokio::fs and instead of running the reqwest::Request::send() calls in series because of the await at the end of each, I threw them into a stream of Futures which lets them run concurrently. Also, Netlify's API has a concurrency limit of 5 requests at any given time for the starter plan & 10 for the paid plans, so I am throttling the Futures to only run at a max concurrency of 5.

Version Updates

Merging this PR will bump all of the applicable packages based on your change files.

netlify_deploy

[0.2.2]

• Trying a final time to fix the workflow
  • f4bd2e2 final tweak to CI on 2021-05-20

Version Updates

Merging this PR will bump all of the applicable packages based on your change files.

netlify_deploy

[0.2.1]

• Updated version-or-publish workflow to get rid of duplicate release, update the release name, and properly populate release body.
  • 30689f4 update workflow on 2021-05-20

Version Updates

Merging this PR will bump all of the applicable packages based on your change files.

netlify_deploy

[0.2.0]

• Added color-eyre and bimap packages.
  • 1dc4cb2 Adding covector on 2021-05-20
• Add flag for deploying to production or not. See #3
  • 1dc4cb2 Adding covector on 2021-05-20
• Cleaning up reqwest logic by inserting headers directly into RequestBuilder chain.
  • 1dc4cb2 Adding covector on 2021-05-20

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.

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.

Motivation

covector added a couple of additional output helpers that allow us to simplify the workflow more than we had previously built. These have recently been published so updating!

Approach

We combined a couple of jobs into 1 and used conditional properties.

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

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.