Guidance: pattern and samples for 1es template adoption (official and unofficial templates)

[chcosta]

This issue tracks this bullet-point from https://github.com/dotnet/dnceng/issues/2148

There is guidance, a pattern and samples for authoring templates that can be shared between official and unofficial, and don't run excessive SDL scans.

[chcosta]

We can conditionalize Microbuild / 1ES template usage via variables. ie, we can propose one of the following patterns.

azure-pipelines.yml

variables:
- ${{ if and(ne(variables['System.TeamProject'], 'public'), in(variables['Build.Reason'], 'Schedule')) }}:
  - name: oneespttemplate
    value: azure-pipelines/MicroBuild.1ES.Official.yml@MicroBuildTemplate
- ${{ if and(ne(variables['System.TeamProject'], 'public'), notIn(variables['Build.Reason'], 'Schedule')) }}:
  - name: oneespttemplate
    value: azure-pipelines/MicroBuild.1ES.Unofficial.yml@MicroBuildTemplate
resources:
  repositories:
  - repository: MicroBuildTemplate
    type: git
    name: 1ESPipelineTemplates/MicroBuildTemplate
    ref: refs/tags/release
extends:
  template: ${{ variables['oneespttemplate'] }}

or

variables.yml

variables:
- ${{ if and(ne(variables['System.TeamProject'], 'public'), in(variables['Build.Reason'], 'Schedule')) }}:
  - name: oneespttemplate
    value: azure-pipelines/MicroBuild.1ES.Official.yml@MicroBuildTemplate
- ${{ if and(ne(variables['System.TeamProject'], 'public'), notIn(variables['Build.Reason'], 'Schedule')) }}:
  - name: oneespttemplate
    value: azure-pipelines/MicroBuild.1ES.Unofficial.yml@MicroBuildTemplate

azure-pipelines.yml

variables:
- template: variables.yml
resources:
  repositories:
  - repository: MicroBuildTemplate
    type: git
    name: 1ESPipelineTemplates/MicroBuildTemplate
    ref: refs/tags/release
extends:
  template: ${{ variables['oneespttemplate'] }}

I don't know that we should provide a "variables.yml" template via Arcade unless we find there to be a consistent pattern for the conditions. It feels like teams will have slightly different needs and need to control the conditions themselves.

FYI @riarenas

[riarenas]

Is there a scenario in which a repo needs to import a different flavor of 1ES template depending on a condition?

What would be the guidance for say, how we are going to refactor job.yml, or the source-build templates so that we can share them between the official and unofficial without so much duplication of the YAML?

[chcosta]

Is there a scenario in which a repo needs to import a different flavor of 1ES template depending on a condition?

My understanding is that "official" applies to builds which produce shipping output, "unofficial" would apply more to an internal CI scenario which doesn't produce shipping assets but validates the build.

[chcosta]

What would be the guidance for say, how we are going to refactor job.yml, or the source-build templates so that we can share them between the official and unofficial without so much duplication of the YAML?

what is your definition of "official" and "unofficial" for this question? ie, are you referring to the 1es.official and 1es.unofficial templates or "official" meaning internal builds and "unofficial" meaning public?

[riarenas]

I'm referring to eng/common/templatesand eng/common/templates-official

[chcosta]

yeah, that's a different issue that we need to consider I actually think there are 3 separate issues (in my mind) for the bullet point which spawned this particular issue.

There is guidance, a pattern and samples for authoring templates that can be shared between official and unofficial, and don't run excessive SDL scans.

1. we have a plan for 1es official / unofficial template adoption (that's this issue)
2. we have a sane approach to manage our templates (that's the issue you are referring to).
3. we have a reasonable pattern for reducing SDL noise which 1es templates incur.

I'll update the name of this issue to be more specific.

[riarenas]

Is 1. future proofing for when we get asked to move non-production to the 1es templates as well?

I just didn't consider that as guidance we needed so that goal, in my mind, was exclusively about 2 and 3.

[riarenas]

Back on topic though! I think this is a good approach for this scenario, and I agree that we don't need to provide the variables via Arcade.

[chcosta]

Is 1. future proofing for when we get asked to move non-production to the 1es templates as well?

yes, it's having an answer for that scenario, and also i wanted to understand it better because it could potentially impact how we approach 2.