Ubuntu update August 2022 [TEST]

[woky]

No description provided.

[woky]

Please ignore this for now. I'm just testing building from Launchpad Git repository.

[tianon]

A couple bits of high-level feedback I'll give you with the goal of helping you avoid redoing work later (:heart:) are that you'll want to make sure Launchpad supports fetching "any sha1" (not just reachable ones, especially if you plan to force push over time) and you'll want to split each architecture into a separate commit/branch/ref (otherwise the download for every server building the image is unnecessarily huge -- when building amd64, we don't need the s390x bits, for example).

There will also be some updates necessary in the docs repo to make sure the Dockerfile links work correctly, but I'm happy to handle that bit (I've got a local change that seems to do the correct thing, generating URLs like https://git.launchpad.net/cloud-images/+oci/ubuntu-base/tree/amd64/Dockerfile?id=a10eb845dceb8d2ef1e415a2c857910189402e3c).

[woky]

Thanks for feedback!

A couple bits of high-level feedback I'll give you with the goal of helping you avoid redoing work later (heart) are that you'll want to make sure Launchpad supports fetching "any sha1" (not just reachable ones, especially if you plan to force push over time)

Yeah, that's doesn't work in Launchpad Git. Been there when I forgot to generate GitFetch field. :-) More on that below.

and you'll want to split each architecture into a separate commit/branch/ref (otherwise the download for every server building the image is unnecessarily huge -- when building amd64, we don't need the s390x bits, for example).

Currently tarballs for $RELEASE are stored with every architecture in docker-library-$RELEASE-$SERIAL branch with single commit history (it's orphaned branch, created with git checkout --orphan ...) and it's never going to be force pushed to (except when same serial is rebuilt, which is only possible by manual intervention). New branch is going to be created for every serial. Example: https://git.launchpad.net/virtustom-cloud-images2/+oci/ubuntu-base/tree/?h=docker-library-22.10-20220801

I chose this because that's how our ($RELEASE-specific) pipeline works. It has access to tarballs for all architectures in one job. Putting tarballs from several releases into single branch would be difficult. However, if it's going to be more efficient for Docker build jobs, I could store the tarballs in docker-library-$RELEASE-$ARCH-$SERIAL (orphan) branches. Would that work with regards to size?

Correct me if I'm wrong please, but I don't think that having so many branches will be be a problem. There's a cleanup in place to remove these branches after 3 months.

There will also be some updates necessary in the docs repo to make sure the Dockerfile links work correctly, but I'm happy to handle that bit (I've got a local change that seems to do the correct thing, generating URLs like https://git.launchpad.net/cloud-images/+oci/ubuntu-base/tree/amd64/Dockerfile?id=a10eb845dceb8d2ef1e415a2c857910189402e3c).

I didn't consider this. I'll look into that later. I expected it'll work out of the box via *-Directory fields.

[woky]

Please see updated library file. Now rootfs tarballs live per release, architecture and serial in docker-library-$RELEASE-$ARCH-$SERIAL branches.

This presented a problem with Tags field though. Initially I've had:

...
+# 20220801 (focal)
Tags: 20.04, focal-20220801, focal
Architectures: amd64
GitFetch: refs/heads/docker-library-20.04-focal-20220801-amd64
GitCommit: 7099ef2a18ebb29ed25867f7114dd447df654e9c

# 20220801 (focal)
Tags: 20.04, focal-20220801, focal
Architectures: arm64v8
GitFetch: refs/heads/docker-library-20.04-focal-20220801-arm64
GitCommit: f07f3f071d8fa3f7c4d9e95055fdd5d9948363f6
...

But naughty PR bot complained about duplicate Tags field. I'm not sure if that's valid complaint as Architectures are disjoint.

I found SharedTags field in other library files but couldn't find any documentation about it. I've tried various variants (like all tags in Tags and SharedTags or all tags in SharedTags and no Tags) but that all failed to validate. I've no idea if SharedTags is what I think it is, but creating one unique Tag with architecture suffix and putting the remaining ones in SharedTags passed the validation:

...
+# 20220801 (focal)
Tags: focal-20220801-amd64
SharedTags: 20.04, focal-20220801, focal
Architectures: amd64
GitFetch: refs/heads/docker-library-20.04-focal-20220801-amd64
GitCommit: 7099ef2a18ebb29ed25867f7114dd447df654e9c

# 20220801 (focal)
Tags: focal-20220801-arm64
SharedTags: 20.04, focal-20220801, focal
Architectures: arm64v8
GitFetch: refs/heads/docker-library-20.04-focal-20220801-arm64
GitCommit: f07f3f071d8fa3f7c4d9e95055fdd5d9948363f6
...

Again, it'd be very difficult to coordinate CI/CD jobs between releases for putting same arch tarballs into one branch. (Provided it's not done by hand which I wanted to avoid.) So I'd be happy to figure out how to do it per release and architecture branches at least.

[woky]

Actually, forget all that please. :-) I shall make the structure same as in https://github.com/tianon/docker-brew-ubuntu-core/ and all these issues will go away. There's no need to create branches specific for docker-library for every pipeline run so the issue I mentioned is not an issue actually. I'll publish new library file later. And description of changes.

[tianon]

Having branch-per-arch-suite combination is totally sane from our PoV -- I'd adjust your example like this to make that work:

# 20220801 (focal)
Tags: 20.04, focal-20220801, focal
Architectures: amd64, arm64v8
amd64-GitFetch: refs/heads/docker-library-20.04-focal-20220801-amd64
amd64-GitCommit: 7099ef2a18ebb29ed25867f7114dd447df654e9c
arm64v8-GitFetch: refs/heads/docker-library-20.04-focal-20220801-arm64
arm64v8-GitCommit: f07f3f071d8fa3f7c4d9e95055fdd5d9948363f6

(The only "catch" is that you need a "global" GitFetch/GitCommit too, but I typically handle that by pointing the global ones to the script branch/head, and those can be common in the global section right next to Maintainers:.)