source-build.yml should use container when running in 1ESPT

[akoeplinger]

https://github.com/dotnet/arcade/blob/767138e3b459adb3fd792b7d68d1213e2de850f3/eng/common/core-templates/jobs/source-build.yml#L9-L11 specifies a default container, but that one will be ignored when running in 1ESPT because it needs the special yml syntax.

Most repos actually haven't noticed this but it causes breaks in repos that set enableInternalSources since after dotnet/arcade#16336 the host image doesn't have the az CLI anymore.

Right now dotnet/templating and dotnet/diagnostics are affected by the break.

We should see if we can specify the container in a 1ESPT-compatible way.

/cc @MichaelSimons

[MichaelSimons]

I experimented in dotnet/templating and was able to get a working solution with the existing arcade templates. In the repo's AzDO pipeline where the 1ES.Pipeline template is used, the container to use in the SB job must be defined. Then the container must be passed as a sourceBuildParameter to the arcade jobs template. This will flow to the source build job and everything will work.

template: v1/1ES.Official.PipelineTemplate.yml@1esPipelines
parameters:
  ...
  containers:
    SourceBuildContainer:
      image: 'mcr.microsoft.com/dotnet-buildtools/prereqs:centos-stream-10-amd64'
      options: --privileged
  stages:
  - stage: build
    displayName: Build
    jobs:
    ...
    - template: /eng/common/templates-official/jobs/jobs.yml@self
      parameters:
        enableSourceBuild: true
        sourceBuildParameters:
          platforms:
          - centosPlatform:
            name: 'CentOS'
            container: SourceBuildContainer
          enableInternalSources: true

The part that is unfortunate is that if the container is not specified to the 1ES.Official template, any job that specifies an invalid container (e.g. the arcade SB job) will simply ignore the container and run directly on the build agent. This provides no indication the AzDO pipeline author did something wrong.

[akoeplinger]

I think we could check that we're in 1ESPT mode and throw an error if the container isn't set?

[akoeplinger]

dotnet/arcade#16456 got me thinking, maybe we should just use that and not specify a default container at all, i.e. repos which need some special container need to explicitly set it, but otherwise repos would just build on the host?

[MichaelSimons]

dotnet/arcade#16456 got me thinking, maybe we should just use that and not specify a default container at all, i.e. repos which need some special container need to explicitly set it, but otherwise repos would just build on the host?

Are you suggesting removing the default container all together or just for the internal 1ES pipeline scenario? Removing it all together is going to break some repos like runtime. Removing the container is going to cause inconsistencies because the host environment will be different across the different environments because the agent changes. That is the benefit of containers. I also don't like relying on dnceng/others if configuration changes are needed - another benefit of containers.

[akoeplinger]

yeah I thought about just removing the default container altogether, repos like runtime already set a custom container image.
if you don't set a container then you're most likely only building managed code and that should work fine on the host.