Integration of OCI delivery in gardenlinux build pipelines

[Vincinator]

Integrate oci delivery gear into Garden Linux build pipelines.

Requirements:

• Implement method to parse all features/*/info.yaml, where input (media types, layers, annotations) is defined for gl-oci #26
• Update Garden Linux features/*/info.yaml files, so that layers, their mediatypes and annotations are defined #16

Tasks:

• Check and set defaults for gardenlinux/gardenlinux use case (path to pub/priv keys)
• Deploy gl-oci in pipelines (check what method is best)

[Vincinator]

Currently debugging an issue where GitHub returns "UNSUPPORTED" operation when pushing a layer blob during the pipelines.

I think we have an issue with asynchrony in general. Multiple jobs try in parallel to edit the OCI-Index. I think we need to handle this differently.

I think the best would be to do the following:

Introduce an additional upload OCI stage, that runs in series[1] for all targets, and then uploads these step by step. This is also true for attaching layers, since the digest is changing and must be updated in the oci-index.

[1] jobs.<job_id>.strategy.max-parallel

[mxmxchere]

I went through the currently failed action steps of the PR and found the following reasons for failed runs:

• missing key or crt for signing, example: https://github.com/gardenlinux/gardenlinux/actions/runs/10525196861/job/29164061337?pr=2292
• failure to download release artifact, example: https://github.com/gardenlinux/gardenlinux/actions/runs/10525196861/job/29164061902?pr=2292#step:6:17
• failure to find an expected file in an artifact, example: https://github.com/gardenlinux/gardenlinux/actions/runs/10525196861/job/29164060822?pr=2292#step:8:239
  • some of those cases might be due to Filter get_oci_metadata by architecture #38 I believe this is the case when the matrix step for example uses arm64 and then complains that there is no amd64 asset.

[mxmxchere]

I also had an error where GitHub returned UNSUPPORTED. That went away when i used glcli oci --insecure

[mxmxchere]

I think we are close to try the GitHub Actions integration again. My current idea: Use https://github.com/gardenlinux/gardenlinux/blob/main/.github/workflows/release-page.yml#L71 as an outset and build a similar, manually triggered action. The linked line provides the relevant context needed for the current state of the program:

• cname
• version
• arch
• release tarball in xz format

The only missing parameter is the registry endpoint (could be hardcoded or supplied via a variable), its credentials and key and certificate for signing/verifying.

[mxmxchere]

A remark regarding the parallel execution using the github matrix approach. This is not safe to use in our context. The same index is altered by all flavors. The alteration process downloads the current state of the index alters it locally and pushes the complete changed version. Although the process is quick it is only a matter of time when a racecondition happens so we have to take it sequentially here.