Automate putting release (and daily) wheels on toolshed

[Conrad Huang]

When a release is made, all wheels other than core should be placed on the toolshed so that they can be updated individually. Currently, there is a mechanism for adding selected wheels to the toolshed (see release() in /usr/local/projects/chimerax/www/preview/cxtoolshed3/apps), but requires manual intervention. We should add a command to upload wheels after release according parameters from the command line and a configuration file. The command can be either added to the release-building script, or invoked manually.

The same process may be applied to the daily build. This means changes must be reflected by version numbers. Whether we use a "dev#" as part of the bundle version number should be discussed.

[Greg Couch]

Many thoughts.

Not sure if we want daily build bundles in the toolshed. We could give the bundles .devTIMESTAMP based on the last git modification to the bundle directory, but the build process would need to change since git is not used in the remote daily build tree.

A bundle "make submit" command would be great. Perhaps a curl or wget that POSTed the wheel could work. How would the OAuth authentication work in that case? Developers will need to know how to build binary packages on all platforms. Maybe we'll need a second daily build of the master branch, and only those bundles would be put in the toolshed.

As part of the candidate release process, we'll need a way to flag bundles that have changed but haven't updated their version number yet.

[Greg Couch]

Won't make 1.3.

[Zach Pearson]

I'm investigating using CircleCI for continuous integration but I think that exploration could apply here. I'm interested in that platform because it works well for repos that either are or can be thouht of like monorepos -- its workflows allow for certain ones to be run just if a folder changes, which I think is more targeted than GitHub Actions currently allows.

[Zach Pearson]

This doesn't need to be milestoned.