Provide release tarballs for containers/storage, containers/image and containers/common

[siretart]

Since the migration to the container-libs monorepo, the individual release tarballs that previously existed for the separate repositories (containers/storage, containers/image, containers/common) are no longer available.

These tarballs were used by multiple downstream distributions (in particular Debian and Ubuntu) as the upstream source for packaging. Our current packaging tooling (gbp, dh-golang, etc.) expects a source tree where the go.mod file is located at the root of the archive. The monorepo tarball (which contains all components under subdirectories and includes a go.work file) cannot be used directly for this purpose.
To keep packaging straightforward and to avoid significant delays when new releases are published, we would kindly ask that the following three release assets continue to be provided with every new tag/release:

containers-storage-<version>.tar.gz
→ contains only the storage directory, renamed so that go.mod is at the root of the tarball (exactly the same layout as https://github.com/containers/storage/archive/v1.59.1.tar.gz had before the monorepo migration)

containers-image-<version>.tar.gz
→ contains only the image directory, renamed so that go.mod is at the root

containers-common-<version>.tar.gz
→ contains only the common directory, renamed so that go.mod is at the root

No vendored dependencies or special distro tarballs are required – the same clean layout that GitHub used to generate automatically for the standalone repositories is perfect.

Having these three assets attached to each release in container-libs (via GitHub Actions automation or any other method) would fully restore the previous workflow and eliminate packaging delays in Debian/Unstable and Ubuntu.

There is no hard deadline, but every new release currently introduces an unfortunate multi-week delay in Debian while we work around the missing tarballs, so restoring this would be very much appreciated by the Debian Go packaging team and our users.

Happy to provide any additional details or help test a proposed automation if needed.
Thank you very much in advance!

[Luap99]

that the following three release assets continue to be provided with every new tag/release:

How would this look exactly? The go monorepo tag layout forces us to use a tag like storage/v1.61.0 to tag only the storage version. And the same for the other modules. As such each tag is one release for one module only so I would assume each GH release then would contain exactly one tarball for the module it was tagged.

Would that be a problem if we have a release called storage/v1.61.0 and then only attach storage-v1.61.0.tar.gz?
Then the same for the other two?

Attaching each tarball to each tag would feel a bit weird though since that would not necessarily be what go get would pull.

Though I guess given the current release process of making sure we always release all modules in sync we could also do one GH release after the common tag gets pushed which then has the three tarballs of the modules as they should all be the same then

There is no hard deadline, but every new release currently introduces an unfortunate multi-week delay in Debian while we work around the missing tarballs, so restoring this would be very much appreciated by the Debian Go packaging team and our users.

One general point, these monorepo layouts are nothing new and defined by go so it feel like the debian tooling should be able to work with that somehow.
I am certainly happy to fix this here if all it takes is to write a bit of github action to build a tarball and attach it, just pointing out that there are more repos like this and getting them all to work in your favour might be harder.

cc @mheon @TomSweeneyRedHat @mtrmac @jankaluza

[mheon]

My initial thought on this was that it would be easiest to only do a proper Github release on c/common releases, and do tarballs of all 3 sub-repos in that. Single GH action instead of 3, always doing the same thing. Though we would have to always do a common release if we bumped storage or image, picking up the newer version... which now that I think of it doesn't really make sense...

[siretart]

Would that be a problem if we have a release called storage/v1.61.0 and then only attach storage-v1.61.0.tar.gz?
Then the same for the other two?

that's actually exactly what I had in mind. I just need the tarballs to continue to look similar as before.