Add "bootstrap" option to ImageBuilder unofficial pipeline #1947
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
mthalman
reviewed
Jan 26, 2026
mthalman
reviewed
Jan 27, 2026
mthalman
approved these changes
Jan 28, 2026
lbussell
added a commit
that referenced
this pull request
Jan 28, 2026
## Summary Fix Windows PR validation failing because ImageBuilder is not pulled. The breaking behavior was added in #1947. Job-specific init steps (customBuildInitSteps, customGenerateMatrixInitSteps, etc.) were being merged into customInitSteps before being passed to init-common.yml. This caused init-imagebuilder.yml to skip the default ImageBuilder pull when any job-specific steps were provided, since it checks if customInitSteps is non-empty. ## Changes - Add separate parameters for job-specific init steps in job templates: - `customBuildInitSteps` in build-images.yml - `customCopyBaseImagesInitSteps` in copy-base-images.yml - `customGenerateMatrixInitSteps` in generate-matrix.yml - Update build-and-test.yml to pass these parameters separately instead of merging them - Add clarifying comments to distinguish the two types of init steps ## Testing Testing via dotnet/dotnet-docker#7016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
Other changes:
init-docker-linuxandinit-docker-windowstemplates into one.Testing: