Caveat: GitHub zips/tarballs are generated on-demand and cached, so they're problematic for bit-for-bit reproducibility:

https://lists.gnu.org/archive/html/bug-guix/2017-10/msg00070...

Of course, you can just clone the git repo.

> Of course, you can just clone the git repo.

Cloning a repo is more intensive on Github's infrastructure then grabbing a zip file or tarball and pushing it into an object store with heavy caching in front of it. There was an open source project that was using excessive resources within Github's infrastructure by using git clone to update itself over a large audience.

https://news.ycombinator.com/item?id=11245652

https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...

Interesting. I'm using them in most of my PKGBUILDs together with once-recoreded SHA256 checksums, and I haven't noticed any reproducibility issues yet.

> zips/tarballs are generated on-demand and cached

Isn't that a deterministic process? I thought if you zipped the same directory twice, you'd get exactly the same bits in the two archives.

Probably a timestamp. They're surprisingly pervasive.

I've been using https://github.com/webpro/release-it to automate releases. It requires your github key and for somereason my github key doesnt persist thru sessions but it works.

Some CI software can trigger jobs automatically when a GitHub release is made, e.g. for Concourse: https://github.com/concourse/github-release-resource

Travis CI has a deployment method for GitHub releases. https://medium.com/@russleyshaw/typescript-package-deploymen... I like to use it to "npm pack" up my new releases and serve them that way.