Heroku deployment configuration

[mvandenburgh]

This PR overhauls the current dandidav deployment process. Currently, we have Heroku configured in a "pull" model, i.e. Heroku constantly pulls our repo and reacts to new commits on main by doing a new deployment. This PR changes this to a "push" model, where we instead explicitly build and deploy the application on push to main via the Heroku CLI in a GitHub Action. Note, a side effect of this is we have complete control over the environment since we're running cargo build in the GitHub Action as opposed to on Heroku; thus, the commit hash issue is no longer a problem.

It contains two components:

• A Procfile for Heroku
  • This defines the command for the web dyno to run in order to start the server
• The GitHub Action that performs the deployment with the Heroku CLI whenever a PR with a "release" label is merged

Other things that need to be done before merging this PR:

• Merge the dandi-infrastructure PR removing the Rust buildpack (Disable Rust buildpack and dyno-metadata feature dandi-infrastructure#170)
• Set the HEROKU_API_KEY and HEROKU_EMAIL secrets on the dandi/dandidav repo

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 46.01%. Comparing base (0b07aa7) to head (c9f6947).
Report is 2 commits behind head on main.

❗ Current head c9f6947 differs from pull request most recent head 23a3521. Consider uploading reports for the commit 23a3521 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #105   +/-   ##
=======================================
  Coverage   46.01%   46.01%           
=======================================
  Files          24       24           
  Lines        3710     3710           
=======================================
  Hits         1707     1707           
  Misses       2003     2003           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jwodder]

I would rather not use auto at all. Instead, deployment should be triggered by any merge of a PR that does not have the "skip deployment" label (See here for a similar trigger definition).

[jwodder]

Is this deploying the entire repository, including the whole of the target/ directory? Can we not just deploy only the target/release/dandidav asset?

[mvandenburgh]

Unfortunately the heroku builds plugin doesn't allow specifying a single asset. And additionally, you have to include the Procfile.

I didn't realize how many files got stored in the target/ directory until I just ran the compilation locally, and I agree it's not ideal to push all those artifacts to Heroku. I tried getting around it by storing things in a temporary directory and pushing that - 6b8df2c

[jwodder]

@mvandenburgh

Set the HEROKU_API_KEY and HEROKU_EMAIL secrets on the dandi/dandidav repo

Set them to what values?

[jwodder]

@mvandenburgh Also, please enable caching of dependencies etc. like is done in test.yml.

[mvandenburgh]

@mvandenburgh

Set the HEROKU_API_KEY and HEROKU_EMAIL secrets on the dandi/dandidav repo

Set them to what values?

I thought we needed someone with admin permissions to set those, but it appears my credentials suffice. So this is all set now

[mvandenburgh]

@jwodder I believe I addressed all your feedback, PTAL and let me know if you have any further questions and/or change requests.

[mvandenburgh]

Also, here is an example of this new workflow running successfully on a different branch - https://github.com/mvandenburgh/dandidav/actions/runs/8273558324/job/22637534296