Skip to content

Commit f2ee44b

Browse files
authored
ci: Test devcontainer image with repos (#118)
I am always afraid that devcontainer internal tests do not catch everything. Thus build the devcontainer locally and test it at multiple repositories, which is quite time consuming. With these tests it is assured that bazel build and test for selected repos and revisions work and stay working.
1 parent aa8222a commit f2ee44b

5 files changed

Lines changed: 132 additions & 12 deletions

File tree

.github/workflows/ci.yaml

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -14,6 +14,7 @@ name: Validate DevContainer
1414
description: This workflow is checking that updates do not break stuff. If on main branch, publish to "latest" tag.
1515
on:
1616
pull_request:
17+
-types: [opened, synchronize, reopened, labeled]
1718
push:
1819
branches:
1920
- main
@@ -71,6 +72,13 @@ jobs:
7172
# Test
7273
./scripts/test.sh
7374
75+
# Test consumer repository, arm64 is skipped because not all bazel dependencies are available for arm64
76+
# By default this is skipped in pull requests, unless the label "test-consumer" is added
77+
if [ "${{ matrix.os }}" = "amd64" ] && ( [ "${{ github.event_name }}" != "pull_request" ] || echo "${{ toJSON(github.event.pull_request.labels) }}" | grep -q "test-consumer" ); then
78+
./scripts/test_consumer.sh "https://github.com/eclipse-score/inc_someip_gateway.git" "14a733a1f3d5f6fa76ac13365d57c8df30b62a86"
79+
./scripts/test_consumer.sh "https://github.com/eclipse-score/score.git" "7cbb86d54dced80e33a6405bc92f8abe62200ad4"
80+
fi
81+
7482
# Optionally: Publish
7583
# We do not use the push feature of devcontainers/ci here, since that would push the wrong container.
7684
# Instead, we use the publish script which pushes the correct container (residing in src/s-core-devcontainer).

README.md

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,7 @@ SPDX-License-Identifier: Apache-2.0
1818
This repository contains the common [development container](https://containers.dev) for [Eclipse S-CORE](https://github.com/eclipse-score).
1919
It contains all tools required to develop (modify, build, ...) Eclipse S-CORE.
2020
All tool version are well-defined, and all tools are pre-configured to work as expected for Eclipse S-CORE development.
21-
The container is [pre-built](https://containers.dev/guide/prebuild) in GitHub Actions as part of this repository, tested, published, and ready for use.
21+
The container is [pre-built](https://containers.dev/guide/prebuild) in GitHub Actions as part of this repository, [tested, published](./docs/ci.md), and ready for use.
2222

2323
Using the pre-built container in an Eclipse S-CORE repository is described in the [Usage](#usage) section.
2424

@@ -312,6 +312,10 @@ The Visual Studio Code instance related to the targeted S-CORE module will now a
312312
If not, press <kbd>Ctrl</kbd> + <kbd>Shift</kbd> + <kbd>p</kbd> and run from there "Dev Containers: Rebuilt Container Without Cache".
313313
Do so, and you have a running instance of `S-CORE DevContainer` related to the targeted S-CORE module.
314314

315+
### Consumer tests
316+
317+
To enable consumer tests in the pull request, read the [ci.md](./docs/ci.md) document.
318+
315319
### Version Pinning
316320

317321
The `S-CORE DevContainer` pins feature and tool versions.

docs/README.md

Lines changed: 0 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -98,14 +98,3 @@ It strengthens the supply chain by pinning versions and hashes, sourcing feature
9898
Pre-built images have a higer availability than the set of all tools which are installed (one download from a location controlled by S-CORE vs. many downloads from "everywhere").
9999
Pre-built images can be easily archived anywhere, e.g. for reproducibility of builds in real production use-cases.
100100
It also enforces a clear separation of concerns: general tooling is delivered through reusable features, S-CORE–specific logic lives in a dedicated feature, and image composition plus publishing are centralized.
101-
102-
## Release Automation
103-
104-
Releases are cut automatically once per week from `main`, but only if commits were added since the latest `v<major>.<minor>.<patch>` tag.
105-
The scheduled workflow creates the git tag and GitHub release, and the existing tag-triggered release workflow then builds, tests and publishes the matching container image.
106-
107-
The next semantic version is derived from commit messages since the previous release:
108-
109-
* breaking changes (`!` in the conventional commit header or `BREAKING CHANGE:` in the body) increment the major version
110-
* `feat` commits increment the minor version
111-
* every other commit increments the patch version so maintenance-only weeks still publish a new immutable image

docs/ci.md

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
<!--
2+
*******************************************************************************
3+
Copyright (c) 2026 Contributors to the Eclipse Foundation
4+
5+
See the NOTICE file(s) distributed with this work for additional
6+
information regarding copyright ownership.
7+
8+
This program and the accompanying materials are made available under the
9+
terms of the Apache License Version 2.0 which is available at
10+
https://www.apache.org/licenses/LICENSE-2.0
11+
12+
SPDX-FileCopyrightText: 2026 Contributors to the Eclipse Foundation
13+
SPDX-License-Identifier: Apache-2.0
14+
*******************************************************************************
15+
-->
16+
17+
# Continuous Integration
18+
19+
The CI workflow (`.github/workflows/ci.yaml`) validates the devcontainer on every pull request, push to `main`, and merge group event.
20+
21+
Builds run on two architectures in parallel:
22+
23+
- **AMD64**
24+
- **ARM64**
25+
26+
The S-CORE devcontainer is build using this repo's `.devcontainer` to ensure consistent behavior at developer and CI.
27+
28+
## Merge Job (main only)
29+
30+
Each architecture is built and tested individually.
31+
After both architecture builds succeed, a merge job creates a multi-arch manifest and pushes it to `ghcr.io`.
32+
It would have been ideal if the multi-arch image could have been build in one go, but that did not work.
33+
34+
## Consumer Tests
35+
36+
At consumer tests, repos using the devcontainer are build and tested using the newly created devcontainer image.
37+
This is done to detect breaking changes before releasing a new devcontainer image and to reduce manual testing efforts.
38+
39+
By default these are not run in pull requests, but in the merge queue and pushes to main to save time.
40+
If these shall be run in the pull request add the **`test-consumer`** label to a pull request.
41+
42+
> [!NOTE]
43+
> Github may not trigger a new workflow run after the label is set.
44+
> You need to push another commit for that.
45+
46+
## Release Automation
47+
48+
Releases are cut automatically once per week from `main`, but only if commits were added since the latest `v<major>.<minor>.<patch>` tag.
49+
The scheduled workflow creates the git tag and GitHub release, and the existing tag-triggered release workflow then builds, tests and publishes the matching container image.
50+
51+
The next semantic version is derived from commit messages since the previous release:
52+
53+
* breaking changes (`!` in the conventional commit header or `BREAKING CHANGE:` in the body) increment the major version
54+
* `feat` commits increment the minor version
55+
* every other commit increments the patch version so maintenance-only weeks still publish a new immutable image

scripts/test_consumer.sh

Lines changed: 64 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,64 @@
1+
#!/usr/bin/env bash
2+
3+
# *******************************************************************************
4+
# Copyright (c) 2026 Contributors to the Eclipse Foundation
5+
#
6+
# See the NOTICE file(s) distributed with this work for additional
7+
# information regarding copyright ownership.
8+
#
9+
# This program and the accompanying materials are made available under the
10+
# terms of the Apache License Version 2.0 which is available at
11+
# https://www.apache.org/licenses/LICENSE-2.0
12+
#
13+
# SPDX-License-Identifier: Apache-2.0
14+
# *******************************************************************************
15+
16+
set -euxo pipefail
17+
18+
# Usage: test_consumer.sh <repo-url> [revision] [devcontainer-image]
19+
# Tests that a consumer repository can be built and tested using the devcontainer.
20+
# It is checked that these commands work without errors:
21+
# - bazel build //...
22+
# - bazel test //...
23+
# Parameters:
24+
# repo-url : Git URL of the consumer repository
25+
# revision : Git branch/tag/commit (default: main)
26+
27+
REPO_URL="${1:?Repository URL is required}"
28+
REVISION="${2:-main}"
29+
30+
IMAGE="s-core-devcontainer"
31+
32+
export DOCKER_BUILDKIT=1
33+
34+
SCRIPT_PATH=$(readlink -f "$0")
35+
SCRIPT_DIR=$(dirname -- "${SCRIPT_PATH}")
36+
PROJECT_DIR=$(dirname -- "${SCRIPT_DIR}")
37+
ID_LABEL="test-container=${IMAGE}"
38+
39+
. "${SCRIPT_DIR}/functions.sh"
40+
set_dockerfile_name
41+
42+
devcontainer up \
43+
--id-label "${ID_LABEL}" \
44+
--workspace-folder "${PROJECT_DIR}/src/${IMAGE}/" \
45+
--remove-existing-container
46+
47+
# Extract repo name from URL
48+
REPO_NAME=$(basename "${REPO_URL}" .git)
49+
REPO_WORKSPACE="/tmp/${REPO_NAME}"
50+
51+
echo "(*) Cloning repository..."
52+
# --revision not supported by older git versions, so we clone first and then checkout the revision
53+
# devcontainer exec --id-label "${ID_LABEL}" git clone --depth 1 --revision "${REVISION}" "${REPO_URL}" "${REPO_WORKSPACE}"
54+
devcontainer exec --id-label "${ID_LABEL}" git clone "${REPO_URL}" "${REPO_WORKSPACE}"
55+
devcontainer exec --id-label "${ID_LABEL}" git -C "${REPO_WORKSPACE}" checkout "${REVISION}"
56+
57+
# Run build and test with Bazel using docker exec
58+
echo "(*) Running Bazel build in devcontainer..."
59+
devcontainer exec --id-label="${ID_LABEL}" /bin/sh -c "set -e && cd \"${REPO_WORKSPACE}\" && bazel build //..."
60+
61+
echo "(*) Running Bazel test in devcontainer..."
62+
devcontainer exec --id-label="${ID_LABEL}" /bin/sh -c "set -e && cd \"${REPO_WORKSPACE}\" && bazel test //..."
63+
64+
echo "(*) Bazel build and test completed successfully for ${REPO_NAME}"

0 commit comments

Comments
 (0)