Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Add new release pipeline with production template #1262

Merged
merged 5 commits into from
Mar 27, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions pipelines/azure-pipelines.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
# Copyright (c) Microsoft Corporation. All rights reserved.
# Licensed under the MIT License.

extends:
template: shared-template.yml@self
parameters:
templateType: UnOfficial
16 changes: 16 additions & 0 deletions pipelines/release-pipeline.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# Copyright (c) Microsoft Corporation. All rights reserved.
# Licensed under the MIT License.
parameters:
- name: enableSemanticRelease
type: boolean
default: false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this pipeline run on every commit (and we manually enable enableSemanticRelease when we want to release), or will this pipeline be manually triggered (and enableSemanticRelease defaults to true via the pipeline variables) ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This pipeline will be CI disabled and will be triggered manually when we want to release. The default value is set to false for accidental manual trigger. So to do the release we manually trigger the pipeline and set the value to true.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible that the official template would detect a blocking issue that the unofficial pipeline would not detect? If that answer is yes, then we should not release until after all official checks have completed. To my mind, the simplest answer is to decouple release from CI, which could take multiple forms:

  1. CI enable the official build with release disabled. To release, we manually trigger the CI build at a validated SHA and with the release flag turned on
  2. Move the publishing into a separate pipeline that consumes artifacts from the pipeline that uses the official template. The official template pipeline could be triggered either manually or on CI (I'd lean toward CI but it's not fully required)
  3. It might be possible to move the release step into a job that runs only after the official pipeline completes successfully. This would require support from the templates and may or may not be something they would want to encourage

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, official template runs extra sdl tools and can detect blocking issue which unofficial would not detect. I think we can go with option 1.

  1. We can go with this option to keep CI enabled and manually trigger the build with release flag turned on. We do not require any further code change for this and enable the CI at pipeline level.
  2. The release task do not consume any artifacts generated in CI pipeline. We are using semantic-release which takes care of everything. For release, we have to just run yarn semantic-release command. So creating separate release will not work well here.
  3. We can try this but the release job will never run until we set the release flag to true manually. It does not make much difference between this and point#1 to me but this will require code changes and testing.


variables:
- name: EnableSemanticRelease
value: ${{ parameters.enableSemanticRelease }}
- group: a11y-insights-axe-sarif-converter-release

extends:
template: shared-template.yml@self
parameters:
templateType: Official
18 changes: 14 additions & 4 deletions azure-pipelines.yml → pipelines/shared-template.yml
Original file line number Diff line number Diff line change
@@ -1,5 +1,13 @@
# Copyright (c) Microsoft Corporation. All rights reserved.
# Licensed under the MIT License.
parameters:
- name: templateType
type: string
default: UnOfficial
values:
- UnOfficial
- Official

# The `resources` specify the location and version of the 1ES PT.
resources:
repositories:
Expand All @@ -11,18 +19,20 @@ extends:
# The pipeline extends the 1ES PT which will inject different SDL and compliance tasks.
# For non-production pipelines, use "Unofficial" as defined below.
# For productions pipelines, use "Official".
template: v1/1ES.Unofficial.PipelineTemplate.yml@1esPipelines
${{ if eq(parameters.templateType, 'Official') }}:
template: v1/1ES.Official.PipelineTemplate.yml@1esPipelines
${{ else }}:
template: v1/1ES.Unofficial.PipelineTemplate.yml@1esPipelines
parameters:
settings:
skipBuildTagsForGitHubPullRequests: true
# Update the pool with your team's 1ES hosted pool.
pool:
name: a11y-insights-pool-dev
name: $(a11yInsightsPool)
image: ubuntu-22.04-secure
os: linux
sdl:
sourceAnalysisPool:
name: a11y-insights-pool-dev # Name of your hosted pool
name: $(a11yInsightsPool) # Name of your hosted pool
image: windows-2022-secure # Name of the image in your pool. If not specified, first image of the pool is used
os: windows # OS of the image. Allowed values: windows, linux, macOS
codeql:
Expand Down