Open lbussell opened 2 months ago
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
[Triage] One downside to this approach would be that we wouldn't test the exact same codepath as the normal eng-validation pipeline if we decide to add extra jobs or stages that inject a new version of ImageBuilder.
Another downside to this would be that if an ImageBuilder change required pipeline changes that are incompatible with the current ImageBuilder version, then CI could never pass (one of the two would always fail - ImageBuilder's Build pipeline or the eng. validation pipeline).
We have two PR validation pipelines in this repo.
This eng validation pipeline runs only when there are changes to the eng/ folder:
https://github.com/dotnet/docker-tools/blob/736b6b0f3ea2923a754a51ec7726074e7fe5ebb7/eng/pipelines/dotnet-docker-tools-eng-validation-pr.yml#L1-L8
However, this does not check when changes in ImageBuilder could affect the way the eng-validation pipeline runs, since it uses the version of ImageBuilder from MAR.
To provide a check for this, we should change the eng-validation pipeline to build and run a new ImageBuilder image, and use that image to run the regular eng-validation-pr pipeline.
One unknown to solve here is how to pass artifacts between stages of public pipeline builds if we don't have access to an ACR. A potential solution to explore is writing the image to the disk and loading it in each successive stage.