release: import umoci's release.sh script

[cyphar]

This script is far easier to use than the previous make release
target, not to mention that it also automatically signs all of the
artefacts and makes everything really easy to do for maintainers.

[I'm going to re-release all of our previous releases using this script.]

Ref: openSUSE/umoci#163
Signed-off-by: Aleksa Sarai [email protected]

[cyphar]

In case you're wondering what the final release artifacts would look like for our last release, here they are:

% tree release
release
└── 1.0.0-rc4
    ├── runc.amd64
    ├── runc.amd64.asc
    ├── runc.sha256sum
    ├── runc.tar.xz
    └── runc.tar.xz.asc

1 directory, 5 files

The really nice thing is that it also provides a signed version of the source code (which is great for openSUSE because OBS supports verifying PGP signatures of source code automatically, but I'm fairly sure that most distributions will appreciate a signed source archive).

Also, since Go supports reproducible builds natively, runc.sha256sum (which contains a clear-sig embedded inside it) also provides useful information for the reproducible builds project.

[hqhq]

This new script is much nicer but the former make release was supposed to build runc with all combinations of build flags, don't know if there are any users depending on that.

[cyphar]

@hqhq I don't think anyone actually wants that, I've personally never used it (nor have I ever actually published them either). Since we're statically compiling the binaries for release, we might as well enable everything. With the ambient stuff maybe there was an argument to not always including everything, but now-a-days all of the features are still optional at run-time.

But if it's really necessary I can modify the script to do that (it will require some changes that I'll also include in umoci to handle multiple binaries to sign).

[hqhq]

@cyphar It's proposed in #899 /cc @crosbymichael should we keep building runc with different build configurations when make release?

[cyphar]

Yeah, and I agreed to it in the past as well. I think I've changed my mind on this topic, after having published several releases, as well as my more recent experience on distribution-related stuff.

[crosbymichael]

I think its fine to have a single build now that most of the features are switched on via the spec.

[dqminh]

Im +1 for just doing a single build with all tags.

[crosbymichael]

And we expect distros that ship only selinux or apparmor to produce their own builds with only the features that they support right?

This is more of our reference build of runc.

[hqhq]

@cyphar OK, I'm +1 for single build as well, needs rebase.

[cyphar]

And we expect distros that ship only selinux or apparmor to produce their own builds with only the features that they support right?

Yeah, distros should generally be building from source (and most importantly, they should be making it dynamically linked) so the binaries we ship aren't really relevant to them. The nice thing about release.sh for distributions is that it will generate signed archives of the source code (which provides better provenance than just pulling an unsigned tag from GitHub -- though I do sign my tags as well).

Rebased.

[hqhq]

LGTM

[crosbymichael]

LGTM

[cyphar]

/me rebuilds all of the latest releases with the new script.