support embargoed builds

[cgwalters]

For RHCOS (and probably others) we want to support embargoed builds, with a flow where select builds are made public once ready.

I'd like to add first-class support to cosa for this. Today we encourage storing builds in S3.

First part of my proposal here is that we decouple a bit more strongly the name or "id" of a build from its "storage identifer". The builds.json might look like this:

{
    "schema-version": "1.0.0",
    "builds": [
        {
            "id": "30.20190818.dev.0",
            "storage": "30.20190818.dev.0-ZDAxOWY2",
            "arches": [
                "x86_64"
            ]
        },
        {
            "id": "30.20190809.dev.1",
            "storage": "30.20190819.dev.1-MTQwNDJm",
            "arches": [
                "x86_64"
            ]
        },
        {
            "id": "30.20190809.dev.0",
            "storage": "30.20190809.dev.0-NTYzOThj",
            "arches": [
                "x86_64"
            ]
        }
    ],
    "timestamp": "2019-08-18T15:16:54Z"
}

Note that there's a random suffix appended to each build's storageid, which would be its object key in S3, replacing the id.

If the bucket is non-enumerable and we make builds.json not publicly readable, then we have implemented the "URL knowledge allows access" pattern.

Then...hm, maybe we have a process that "promotes" a build we want to make public into a separate release stream?

[cgwalters]

Then...hm, maybe we have a process that "promotes" a build we want to make public into a separate release stream?

Thinking about this led me to coreos/fedora-coreos-tracker#98 which I don't quite understand how it works today. As of today also, RHCOS does not use plume - it's not clear to me we should?

I still feel the parts of mantle that are like big conditionals on if (CL) else if (FCOS) else if ()... are very awkward and we'd gain a lot if we punted all the CL stuff to a branch. That would also make it a bit more obvious if we tried to do things like have RHCOS use plume.

[cgwalters]

Eh, thinking about this more it is simpler to skip the storageid stuff and just have a fully private release stream that has a subset promoted public. The advantage of storageid is that it makes it possible to easily share pre-promoted builds with 3rd parties to test...but eh, we can always do that later after we have good support in cosa for a promotion flow (including from private ➡️ public).

[jlebon]

I think where we went with this now is simply to ensure that we don't build RHCOS with embargoed packages. Not sure if we'll go back on that.