Skip to content

Conversation

@lbussell
Copy link
Member

@lbussell lbussell commented Jan 23, 2026

Background: Testing ImageBuilder changes end-to-end (code + pipelines) requires building and pushing an image to a registry and manually updating the ImageBuilder code reference for every code change. This limits how quickly you can iterate on larger ImageBuilder changes.

This PR: adds a bootstrapImageBuilder parameter to the imagebuilder-unofficial pipeline. When enabled, ImageBuilder is built from source at the start of every job. This enables validating ImageBuilder source changes and pipeline template changes together in a single pipeline run.

Linux builds the container directly using docker build, tags the image, and overrides the imagebuilder image variable so that it's used for later steps. Windows builds directly using .NET, and puts the output in the place that subsequent steps expect. In this sense, it's different from the pipeline build, since it's not built using ImageBuilder. That's why it's a "bootstrap". I determined that this would be OK because the pipeline itself will then proceed to validate that build ImageBuilder can build ImageBuilder.

Other options I considered:

  • Conditionally adding a build stage before the first build stage to build ImageBuilder just in time. This won't work because that stage might be broken due to pipeline changes.
  • Separate pipeline that runs the ImageBuilder image build and triggers another pipeline to validate the changes with that version of ImageBuilder. It's the same problem though - if you make breaking changes to the pipeline, then one of the two will fail.

Other changes:

  • Combined init-docker-linux and init-docker-windows templates into one.
  • The bootstrap code and options are all only in this repo and won't affect consuming repos. This is through a new parameter that allows overriding the imagebuilder initialization steps.

Testing:

Use Build.Repository.LocalPath instead of relative paths so the
bootstrap template works correctly when versionsRepoRef is set,
which triggers multi-repo checkout and changes the directory structure.
In multi-repo checkout scenarios, Build.Repository.LocalPath points to
the parent directory containing both repos. Add repoRoot and versionsRepoRoot
variables that resolve to the correct paths in both single and multi-repo
checkout modes.

- repoRoot: Always points to the source repo root
- versionsRepoRoot: Points to versions repo in multi-repo mode

Remove duplicate versionsRepoRoot calculation from publish.yml since it's
now set centrally in init-matrix-build-publish.yml.
@lbussell lbussell requested a review from a team as a code owner January 23, 2026 23:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant