[vitaly-zdanevich]

Distributions that build packages without network access need the Go module dependencies as a
separate tarball next to the source archive. This is common practice: Gentoo, openSUSE
(obs-service-go_modules) and Fedora
(go-vendor-tools) all package Go software
with a vendor tarball, and Gentoo's guide for Go ebuilds recommends asking upstream to generate
the tarball in CI: https://wiki.gentoo.org/wiki/Writing_go_Ebuilds#Packaging_the_dependencies

I maintain a Gentoo ebuild for spanner-cli
(https://github.com/vitaly-zdanevich/gentoo-overlay/tree/main/dev-db/spanner-cli). Because the
repository has no vendor directory, I currently generate and host the tarball myself; attaching
it to the releases here would let the ebuild, and other package managers, download it from
upstream instead.

This workflow runs go mod vendor when a release is published and uploads
spanner-cli-X.Y.Z-vendor.tar.xz to that release. It can also be run manually for an existing
tag, so it could attach a tarball to v0.11.2 as well. The tarball is reproducible (sorted
entries, fixed owner and modification time), so re-running the workflow uploads identical bytes.
The existing release process doesn't change.

Tested locally for v0.11.2: two runs produce byte-identical tarballs (3.4 MB), and the GitHub
source archive plus this tarball builds with GOPROXY=off. actionlint reports no findings for
the new workflow.

[yfuruyama]

Thank you for filing a PR, but sorry we cannot accept this change.

• spanner-cli is in maintenance mode, so we only accept critical fixes.
• We encourage users to use go install to install the command.
• Maintaining a new github workflow have a potential risk for security issues.