many: make two builds of core26, one with and one without cloud-init#423
Conversation
Make building core26 with cloud-init optional: do not include by default but build with it when the cloud-init-build marker file exists. This allows building variants with or without cloud-init support from the same codebase.
Add logic to automatically detect cloud-init builds based on branch naming convention. A marker file is created when the current branch ends with '-cloud-init', enabling conditional inclusion of cloud-init in the build.
as now we have snaps published in that channel.
There was a problem hiding this comment.
Pull request overview
This PR introduces a build-time “variant” mechanism for core26 so CI/CD can produce two base snaps: one that includes cloud-init and one that excludes it.
Changes:
- Add a
cloud-init-buildmarker-file mechanism to toggle cloud-init inclusion during snap build. - Update hook execution to conditionally apply cloud-init-specific configuration and unit enablement based on
SNAP_CLOUD_INIT_BUILD. - Matrix GitHub Actions workflows to build/test both “regular” and “cloud-init” variants (with skips for bases where cloud-init is already default).
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| tests/lib/prepare-utils.sh | Creates cloud-init-build marker during spread build based on BUILD_VARIANT. |
| snapcraft.yaml | Conditionally includes cloud-init_bins slice when marker exists; adds slices needed when cloud-init isn’t default; updates build-snaps to core26. |
| Makefile | Exports SNAP_CLOUD_INIT_BUILD for hook scripts based on marker presence. |
| hooks/011-cloud-init-config.chroot | Runs cloud-init-specific config edits only when SNAP_CLOUD_INIT_BUILD=true. |
| hooks/005-initialize-systemd.chroot | Conditionally enables cloud-init systemd units based on SNAP_CLOUD_INIT_BUILD. |
| .github/workflows/tests.yaml | Adds a build/test matrix over variant: [regular, cloud-init] and variant-scoped artifact names. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| cd "$project_dir" | ||
| if [ "$BUILD_VARIANT" = cloud-init ] | ||
| then touch cloud-init-build | ||
| fi | ||
| snapcraft pack --verbosity verbose |
There was a problem hiding this comment.
build_base_snap creates cloud-init-build when BUILD_VARIANT=cloud-init, but it never removes the marker when building the regular variant. If the same project_dir is reused across builds (e.g., local dev running both variants in sequence), the marker can persist and cause a "regular" build to accidentally include cloud-init. Consider explicitly removing cloud-init-build (or building in a clean directory) when BUILD_VARIANT is not cloud-init.
| tests-snapd: | ||
| runs-on: ubuntu-latest | ||
| needs: build | ||
| strategy: | ||
| fail-fast: false | ||
| matrix: | ||
| variant: [regular, cloud-init] | ||
| # Skip cloud-init variant for bases that had it included by default | ||
| if: ${{ !((startsWith(github.ref_name, 'core22') || startsWith(github.ref_name, 'core24')) && matrix.variant == 'cloud-init') }} | ||
| env: | ||
| BUILD_VARIANT: ${{ matrix.variant }} | ||
| steps: |
There was a problem hiding this comment.
tests-snapd is now matrixed over variant: [regular, cloud-init], but the image boot/SSH helper (tests/lib/prepare-utils.sh) SSHes as user test@localhost (created via cloud-init config) and the workflow still relies on prepare_base_cloudinit to inject a cloud-init config into the gadget. The "regular" variant (intended to be built without cloud-init) is likely to never create the test user, causing the VM boot step to time out. Consider running tests-snapd only for the cloud-init variant (or updating the VM/user provisioning to not depend on cloud-init for the regular build).
| # recipe, and then removed. | ||
| ( | ||
| cd "$CRAFT_PROJECT_DIR" | ||
| if git branch --show-current | grep '.*-cloud-init$' |
There was a problem hiding this comment.
The branch detection pipeline will print the branch name into the build logs because grep is not quiet. Using grep -q (and potentially anchoring to -cloud-init$ without .*) would avoid noisy output while keeping the same behavior.
| if git branch --show-current | grep '.*-cloud-init$' | |
| if git branch --show-current | grep -q -- '-cloud-init$' |
alfonsosanchezbeato
force-pushed
the
separate-cloud-init
branch
3 times, most recently
from
eb0cb7b to
3deb55c
Compare
system-user assertion
Add base-variant input parameter to run-spread-tests action to support different base image types (regular or cloud-init). Export BUILD_VARIANT environment variable and pass the variant through workflow test jobs. Also update external tests to use ubuntu-core-26-64 and remove inline cloud-init preparation in favor of variant-based approach.
Add conditional SSH authentication based on BUILD_VARIANT (cloud-init vs system-user).
as in some cases we hack the user into a script inside the snapd snap.
What we have now is invalid if installing from the initramfs.
Only run tests for one variant since the user is introduced by modifying the snapd snap, and neither cloud-init nor system-user assertions are used.
- Define SSH_PRIVATE_KEY variable at the top of the file Replace - hardcoded path with variable reference in execute_remote Add chmod - to fix permissions when file is copied (repo permissions not - respected) ```
alfonsosanchezbeato
force-pushed
the
separate-cloud-init
branch
from
6c6bd4f to
d3c6a13
Compare
No description provided.