CI: Publish binaries with ORAS

[mkulke]

Pushing artifacts as binaries to the project's GHCR. The build job is split between AA and CDH+ASR. AA has specific build and runtimerequirements depending on the TEE, while the CDH+ASR are generic per arch.

Hence $AA is tagged with $sha-$tee ($arch is implicit in $tee) while CDH+ASR are tagged with $sha-$arch.

Why

Peerpod as a downstream project currently builds GC binaries as part of their pipeline. This is rather costly, the project is written in golang and needs to maintain a complex rust build infra for GC that often drifts in terms of rust-versions, feature-toggles and makes it hard to keep up to date with recent GC. There's also considerable overhead in terms of build-time.

It makes sense to have canonical cache of build-artifacts that can be consumed downstream.

[stevenhorsman]

A few comments/questions. Overall it looks good though

[stevenhorsman]

One optional comment, but it's looking good

[dcmiddle]

Not trying to be pedantic, just checking my understanding...
This isn't publishing to oras. It is publishing using the oras cli, which pushes to a specified registry, e.g. ghcr.
Is that right?

[mkulke]

Edit: I added build attestations for those artifacts, which is a rather new gh feature. we might want to use them when consuming the binaries:

gh attestation verify oci://ghcr.io/mkulke/guest-components/api-server-rest@sha256:251cfcbd73a625b1224b7f5b8d639ab93779650e8c42aaa5bdf4636fa00d7922 -o mkulke
Loaded digest sha256:251cfcbd73a625b1224b7f5b8d639ab93779650e8c42aaa5bdf4636fa00d7922 for oci://ghcr.io/mkulke/guest-components/api-server-rest@sha256:251cfcbd73a625b1224b7f5b8d639ab93779650e8c42aaa5bdf4636fa00d7922
Loaded 1 attestation from GitHub API
✓ Verification succeeded!

sha256:251cfcbd73a625b1224b7f5b8d639ab93779650e8c42aaa5bdf4636fa00d7922 was attested by:
REPO                     PREDICATE_TYPE                  WORKFLOW
mkulke/guest-components  https://slsa.dev/provenance/v1  .github/workflows/publish-artifacts.yml@refs/heads/mkulke/test

we can assert some facts about the build status:

gh attestation verify oci://ghcr.io/mkulke/guest-components/api-server-rest@sha256:251cfcbd73a625b1224b7f5b8d639ab93779650e8c42aaa5bdf4636fa00d7922 -o mkulke --format json | jq .[].verificationResult.signature.certificate
{
  "certificateIssuer": "CN=sigstore-intermediate,O=sigstore.dev",
  "subjectAlternativeName": "https://github.com/mkulke/guest-components/.github/workflows/publish-artifacts.yml@refs/heads/mkulke/test",
  "issuer": "https://token.actions.githubusercontent.com",
  "githubWorkflowTrigger": "push",
  "githubWorkflowSHA": "65ecab01e3f3e3e89653977b15078e02b9a46698",
  "githubWorkflowName": "Publish artifacts to ORAS",
  "githubWorkflowRepository": "mkulke/guest-components",
  "githubWorkflowRef": "refs/heads/mkulke/test",
  "buildSignerURI": "https://github.com/mkulke/guest-components/.github/workflows/publish-artifacts.yml@refs/heads/mkulke/test",
  "buildSignerDigest": "65ecab01e3f3e3e89653977b15078e02b9a46698",
  "runnerEnvironment": "github-hosted",
  "sourceRepositoryURI": "https://github.com/mkulke/guest-components",
  "sourceRepositoryDigest": "65ecab01e3f3e3e89653977b15078e02b9a46698",
  "sourceRepositoryRef": "refs/heads/mkulke/test",
  "sourceRepositoryIdentifier": "651443953",
  "sourceRepositoryOwnerURI": "https://github.com/mkulke",
  "sourceRepositoryOwnerIdentifier": "273280",
  "buildConfigURI": "https://github.com/mkulke/guest-components/.github/workflows/publish-artifacts.yml@refs/heads/mkulke/test",
  "buildConfigDigest": "65ecab01e3f3e3e89653977b15078e02b9a46698",
  "buildTrigger": "push",
  "runInvocationURI": "https://github.com/mkulke/guest-components/actions/runs/11148465609/attempts/1",
  "sourceRepositoryVisibilityAtSigning": "public"
}

I'm curious how this will look on private runners @BbolroC @stevenhorsman did you use that yet on s390x?

[mkulke]

Not trying to be pedantic, just checking my understanding... This isn't publishing to oras. It is publishing using the oras cli, which pushes to a specified registry, e.g. ghcr. Is that right?

yes, albeit there's some conventions/annotations attached when using the oras cli to push to a registry. technically correct would be "pushing to OCI w/ oras"

[stevenhorsman]

I'm curious how this will look on private runners @BbolroC @stevenhorsman did you use that yet on s390x?

Not as far as I know. @BbolroC is (also) on public holiday today, but might have more info. I think we give it a try and see how it looks.

[mkulke]

I'm curious how this will look on private runners @BbolroC @stevenhorsman did you use that yet on s390x?

Not as far as I know. @BbolroC is (also) on public holiday today, but might have more info. I think we give it a try and see how it looks.

@stevenhorsman it looks like oras installer doesn't support the ibm arch, but I suppose it's a bug, since the project publishes s390x packages, now?

[stevenhorsman]

@stevenhorsman it looks like oras installer doesn't support the ibm arch, but I suppose it's a bug, since the project publishes s390x packages, now?

Yeah, maybe just an issue with the action?

[stevenhorsman]

It looks from https://github.com/oras-project/setup-oras/blob/4e826cc60c14f9b275cce0ad4ed390c040de5099/src/lib/release.ts#L95-L100 like it is expecting arch of s390, not s390x. We might need some help from Choi to confirm what the settings are, but we might want a patch to support both

[mkulke]

It looks from https://github.com/oras-project/setup-oras/blob/4e826cc60c14f9b275cce0ad4ed390c040de5099/src/lib/release.ts#L95-L100 like it is expecting arch of s390, not s390x. We might need some help from Choi to confirm what the settings are, but we might want a patch to support both

oras-project/setup-oras#57

[stevenhorsman]

oras-project/setup-oras#57

Nice - beat me too it :)