Please attach a stable source archive to releases

[jmillikin]

Releases of Error Prone currently get Git tags and release entries recorded under https://github.com/google/error-prone/releases, but those releases don't have stable source archives attached to them. The only archives offered are via GitHub's automatic tarball endpoints, which are equivalent to running git archive.

GitHub does not guarantee that it always returns the exact same bytes for a tarball of a given commit/tag. This can be frustrating for users of Bazel (and similar build tools), which validates downloaded archives against an expected checksum.

Examples of user-reported build breakage that has been caused in the past by GitHub archive checksum changes:

• Protobuf: sha256 changes on v3.3.0, v3.3.1? protocolbuffers/protobuf#3619
• Bazel: How to depend on Bazel release (not on the tarball from Github of 0.5.4 tag -> checksum changed) bazelbuild/bazel#3722
• Kubernetes: bazel build failure: SHA of remote archive changed kubernetes/kubernetes#52307

An easy solution is to have the release management script download the auto-generated tarball from GitHub and then upload it as an attachment to the release. That way, if the automatic tarball endpoint's output ever changes (e.g. due to different compression output) the stable archive's checksum will remain the same.

Alternatively, a command such as git archive --format=tar $TAG | gzip -9 > errorprone-${TAG}.tar.gz can be used to generate the tarball locally.

[cpovirk]

(I'm more of an occasional contributor, not a core team member here, but:)

Thanks, I remember hearing of this before, I think with our "bazel-common" repo, for which we now use git_override? I assume that bringing Git into the picture is better to avoid where possible and so a plain old jar is preferable? Is the sources jar in Maven Central workable, or could we make changes to its format in future releases so that it would work?

[jmillikin]

In general HTTP(S) is preferable to Git because Bazel has a lot of machinery for local caching, proxying, and verification of HTTP downloads, but Git downloads are just shelling out to git.

I don't have a strong preference for tarballs vs source jars, but the source jars hosted on Maven appear to be for subsets of the Error Prone sources. If a dependency is split into multiple small archives then updating it can be a hassle (lots of URLs and checksums to juggle).

• https://repo1.maven.org/maven2/com/google/errorprone/error_prone_core/2.36.0/error_prone_core-2.36.0-sources.jar is bugpatterns/, refaster/, and scanner/
• https://repo1.maven.org/maven2/com/google/errorprone/error_prone_annotations/2.36.0/error_prone_annotations-2.36.0-sources.jar is annotations/ (with type_annotations/ being separate?)
• (etc)

For huge multi-project repos a split archive might be worth it, but Error Prone's _core source jar isn't much smaller than the GitHub archive tarball:

-rw-r--r--  1 john  staff  2818055 Feb 20 23:05 error_prone_core-2.36.0-sources.jar
-rw-r--r--  1 john  staff  2887918 Feb 20 23:15 error-prone-2.36.0.tar.gz

So my first preference would be a copy of the source as it exists in source control, hosted on GitHub. Second preference would be an "all sources" source jar hosted on Maven. Neither one seems to exist currently, as far as I can tell.