Automate Container Image Build and Push #23

New issue

Open

opened 2026-01-09 14:03:57 +00:00 by janhalen · 3 comments

janhalen commented

2026-01-09 14:03:57 +00:00

(Migrated from github.com)

Description

Establish an automated process to build the openclient-core operating system image. This ensures that every update to the repository results in a new, versioned image stored in the GitHub Container Registry, ready for deployment.

Define the Build Workflow
- Create a build YAML file
Configure the Build Environment
- Define the automation to trigger (e.g. on "push" events to the main branch.)
- Use a build runner (e.g. like quay.io/buildah/stable) to host the build process.
Establish Registry Authentication
- Use the built-in GITHUB_TOKEN to allow the automation to securely log into the GitHub Container Registry.
Build the Image
- Use the standard tooling in the selected portable environment build the image using the selected portable build environment.
Apply Version Tags
- Configure the automation to tag the image with a semantic version and a secondary tag using the unique "Commit SHA" for precise version tracking.
Push and Verify
- Manually verify the image is visible in the container image repo.

Definition of Done

The image build is performed inside a portable build environment container, (not via a GitHub-managed plugin.)
The resulting image is successfully pushed to the registry.
The build script has been tested locally to ensure portability.
The system is ready to be migrated to a self-hosted forge if required.

## Description Establish an automated process to build the `openclient-core` operating system image. This ensures that every update to the repository results in a new, versioned image stored in the GitHub Container Registry, ready for deployment. * [ ] **Define the Build Workflow** * Create a build YAML file * [ ] **Configure the Build Environment** * Define the automation to trigger (e.g. on "push" events to the `main` branch.) * Use a build runner (e.g. like `quay.io/buildah/stable`) to host the build process. * [ ] **Establish Registry Authentication** * Use the built-in `GITHUB_TOKEN` to allow the automation to securely log into the GitHub Container Registry. * [ ] **Build the Image** * Use the standard tooling in the selected portable environment build the image using the selected portable build environment. * [ ] **Apply Version Tags** * Configure the automation to tag the image with a semantic version and a secondary tag using the unique "Commit SHA" for precise version tracking. * [ ] **Push and Verify** * Manually verify the image is visible in the container image repo. ## **Definition of Done** * [ ] The image build is performed inside a portable build environment container, (not via a GitHub-managed plugin.) * [ ] The resulting image is successfully pushed to the registry. * [ ] The build script has been tested locally to ensure portability. * [ ] The system is ready to be migrated to a self-hosted forge if required.

janhalen commented

2026-01-09 14:09:04 +00:00

(Migrated from github.com)

@ChatBotBerg & @turegjorup : Can you make the needed agreements to put this "in the books"

@turegjorup please comment, critique and suggest changes to this high level issue description and give an estimate when we agree on a set of minimal tasks to meet the DoD.

@ChatBotBerg & @turegjorup : Can you make the needed agreements to put this "in the books" @turegjorup please comment, critique and suggest changes to this high level issue description and give an estimate when we agree on a set of minimal tasks to meet the DoD.

rriemann commented

2026-03-19 20:12:28 +00:00

(Migrated from github.com)

Hello,

we accomplish all these tasks with https://blue-build.org/ in our repo https://gitlab.com/eu-os/workspace-images/eu-os-base-demo . blue-build relies (as far as I know) on buildah. The image is ghcr.io/blue-build/cli:v0.9:

From our gitlab ci file:

build_image:
  <<: *all_recipes
  stage: build
  image:
    name: ghcr.io/blue-build/cli:v0.9
    entrypoint:
    - ''
  services:
  - docker:dind
  variables:
    DOCKER_HOST: tcp://docker:2376
    DOCKER_TLS_CERTDIR: "/certs"
    DOCKER_TLS_VERIFY: 1
    DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client"
    RUST_LOG_STYLE: always
    CLICOLOR_FORCE: 1
    BB_CACHE_LAYERS: "true"
    # BB_REGISTRY_NAMESPACE: ""
  before_script:
  - curl --silent "https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/download-secure-files/-/raw/main/installer"
    | bash
  - export COSIGN_PRIVATE_KEY=$(cat .secure_files/cosign.key)
  script:
  - sleep 5
  - bluebuild build -vv -S sigstore --push ./recipes/$RECIPE # --platform linux/amd64/v2

Source: https://gitlab.com/eu-os/workspace-images/eu-os-base-demo/-/blob/main/.gitlab-ci.yml?ref_type=heads

Hello, we accomplish all these tasks with https://blue-build.org/ in our repo https://gitlab.com/eu-os/workspace-images/eu-os-base-demo . blue-build relies (as far as I know) on buildah. The image is `ghcr.io/blue-build/cli:v0.9`: From our gitlab ci file: ~~~yaml build_image: <<: *all_recipes stage: build image: name: ghcr.io/blue-build/cli:v0.9 entrypoint: - '' services: - docker:dind variables: DOCKER_HOST: tcp://docker:2376 DOCKER_TLS_CERTDIR: "/certs" DOCKER_TLS_VERIFY: 1 DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client" RUST_LOG_STYLE: always CLICOLOR_FORCE: 1 BB_CACHE_LAYERS: "true" # BB_REGISTRY_NAMESPACE: "" before_script: - curl --silent "https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/download-secure-files/-/raw/main/installer" | bash - export COSIGN_PRIVATE_KEY=$(cat .secure_files/cosign.key) script: - sleep 5 - bluebuild build -vv -S sigstore --push ./recipes/$RECIPE # --platform linux/amd64/v2 ~~~ Source: https://gitlab.com/eu-os/workspace-images/eu-os-base-demo/-/blob/main/.gitlab-ci.yml?ref_type=heads

janhalen commented

2026-03-23 07:46:40 +00:00

(Migrated from github.com)

Hello @rriemann !

We really appreciate you sharing your setup and the link to your GitLab CI configuration. It’s very insightful to see how you’re leveraging buildah and your specific implementation details with blue-build —thank you for the transparency.

While we value the work being done in the blue-build community, the nornnet project has a strict requirement for OCI-native standardization. We are intentionally avoiding additional abstraction layers or specialized CLI wrappers to prevent any form of tool- and/or vendor- lock-in.

By sticking exclusively to the standard Open Container Initiative Containerfile DSL, we ensure our images remain fully portable and compatible with the entire cloud-native ecosystem and security tooling by default. Our priority is long-term maintainability rooted in industry standards rather than emerging community-specific DSLs like blue-build

That said, we’d love to explore touchpoints for collaboration in the future. If your stack moves further toward OCI-standardized workflows, please let us know. We’d be very interested in exploring how our efforts in Linux device management could align.

Thanks again for reaching out and showing us your approach!

Hello @rriemann ! We really appreciate you sharing your setup and the link to your GitLab CI configuration. It’s very insightful to see how you’re leveraging `buildah` and your specific implementation details with `blue-build` —thank you for the transparency. While we value the work being done in the `blue-build` community, the nornnet project has a strict requirement for OCI-native standardization. We are intentionally avoiding additional abstraction layers or specialized CLI wrappers to prevent any form of tool- and/or vendor- lock-in. By sticking exclusively to the standard [Open Container Initiative](https://opencontainers.org/) Containerfile DSL, we ensure our images remain fully portable and compatible with the entire cloud-native ecosystem and security tooling by default. Our priority is long-term maintainability rooted in industry standards rather than emerging community-specific DSLs like `blue-build` That said, we’d love to explore touchpoints for collaboration in the future. If your stack moves further toward OCI-standardized workflows, please let us know. We’d be very interested in exploring how our efforts in Linux device management could align. Thanks again for reaching out and showing us your approach!