[#587] Build OCI images for release tags #588

potyarkin · 2024-12-18T11:22:52Z

potyarkin commented

2024-12-18 11:22:52 +00:00

OCI images will be built often (on each PR) to make sure our recipe doesn't go stale.
Publishing to the registry will happen only for v* tags.
workflow_dispatch can be used to trigger the job manually without modifying the repository. This can come handy if we'll need to incorporate upstream changes in base image (e.g. root CA certificates)
Image builds will start in parallel with regular builds and linters. Skipping image build for PRs which fail other checks could save some compute resources but would introduce an unnecessary delay for "green" builds. Developer time is a more scarce resource, let's not waste it.

TODO:

Add registry token to org secrets. Done: @snegurochka's token works in another repo since today.
Switch to git.frostfs.info as canonical registry for our images (instead of Docker Hub): #590

- OCI images will be built often (on each PR) to make sure our recipe doesn't go stale. - Publishing to the registry will happen only for `v*` tags. - `workflow_dispatch` can be used to trigger the job manually without modifying the repository. This can come handy if we'll need to incorporate upstream changes in base image (e.g. root CA certificates) - Image builds will start in parallel with regular builds and linters. Skipping image build for PRs which fail other checks could save some compute resources but would introduce an unnecessary delay for "green" builds. Developer time is a more scarce resource, let's not waste it. TODO: - [x] Add registry token to org secrets. Done: @snegurochka's token works in [another repo](https://git.frostfs.info/TrueCloudLab/-/packages/container/env/versions) since today. - [x] Switch to git.frostfs.info as canonical registry for our images (instead of Docker Hub): #590

potyarkin force-pushed feature/ci-build-oci-image from 72fac6a60e to 9593f7bc75

2024-12-18 11:33:01 +00:00

Compare

potyarkin force-pushed feature/ci-build-oci-image from 9593f7bc75 to 9da9cb85e3

2024-12-18 11:40:12 +00:00

Compare

potyarkin force-pushed feature/ci-build-oci-image from 9da9cb85e3 to 3780f7b816

2024-12-18 12:50:13 +00:00

Compare

potyarkin self-assigned this 2024-12-18 13:12:30 +00:00

potyarkin added the

Infrastructure

label 2024-12-18 13:12:38 +00:00

potyarkin referenced this pull request

2024-12-18 13:44:21 +00:00

Use selfhosted OCI registry instead of Docker Hub #590

potyarkin referenced this pull request

2024-12-18 13:53:27 +00:00

Push release images to OCI registry from Forgejo Actions #587

potyarkin force-pushed feature/ci-build-oci-image from 3780f7b816 to 642fc27d32

2024-12-20 14:44:10 +00:00

Compare

potyarkin changed title from ~~WIP: [#587] Build OCI images for release tags~~ to [#587] Build OCI images for release tags

2024-12-23 09:21:26 +00:00

potyarkin requested review from storage-services-developers 2024-12-23 09:21:26 +00:00

potyarkin requested review from storage-services-committers 2024-12-23 09:21:26 +00:00

potyarkin commented

2024-12-23 09:22:56 +00:00

I believe we're ready to merge this.

After merge we can trigger a manual build for one of existing tags, and if everything goes OK, I'll create similar PRs for other repos.

I believe we're ready to merge this. After merge we can trigger a manual build for one of existing tags, and if everything goes OK, I'll create similar PRs for other repos.

potyarkin requested review from alexvanin 2024-12-23 09:23:09 +00:00

dkirillov approved these changes 2024-12-23 11:50:37 +00:00

alexvanin reviewed 2024-12-24 08:15:36 +00:00

.forgejo/workflows/oci-image.yml

					
				@ -0,0 +1,27 @@

				on:

				  pull_request:

				  push:

				  workflow_dispatch:

alexvanin commented

2024-12-24 08:15:36 +00:00

Am I right that this job is going to be triggered on every push / pr merge, however it will build image only when commit contains release tag according to condition?

startsWith(github.ref, 'refs/tags/v')

Am I right that this job is going to be triggered on every push / pr merge, however it will build image only when commit contains release tag according to condition? ``` startsWith(github.ref, 'refs/tags/v') ```

potyarkin commented

2024-12-25 07:43:52 +00:00

No, the job will build the image (make image) for each push/PR but will publish the image (make image-push) only for release tags. This is somewhat wasteful: we will build a lot of images we don't need, and I welcome suggestions on how to reduce that waste.

Disabling image builds for everything except release tags can (and probably will) backfire: we may push a release tag and find out that our image build pipeline is broken only after the fact. A clean manual workaround would not be possible: modified build recipes would make our repo tree diverge from the tagged version, and pushing such image under the release tag would not be fair.

The workflow suggested in this PR would exercise image build pipeline often and we would notice its failure long before pushing a new release. The only step not covered would be image-push: in case of job failure a manual push would not dirty the worktree and would not introduce any misinformation to the published artifact.

No, the job will build the image (`make image`) for each push/PR but will publish the image (`make image-push`) only for release tags. This is somewhat wasteful: we will build a lot of images we don't need, and I welcome suggestions on how to reduce that waste. Disabling image builds for everything except release tags can (and probably will) backfire: we may push a release tag and find out that our image build pipeline is broken only after the fact. A clean manual workaround would not be possible: modified build recipes would make our repo tree diverge from the tagged version, and pushing such image under the release tag would not be fair. The workflow suggested in this PR would exercise image build pipeline often and we would notice its failure long before pushing a new release. The only step not covered would be `image-push`: in case of job failure a manual push would not dirty the worktree and would not introduce any misinformation to the published artifact.

👍 1