-
Notifications
You must be signed in to change notification settings - Fork 541
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
Updates "include-publish-npm-package-deployment" pipeline deployment job to be 1ES compliant #23913
base: main
Are you sure you want to change the base?
Updates "include-publish-npm-package-deployment" pipeline deployment job to be 1ES compliant #23913
Conversation
…o separate build step
…to test/seanimam/updatePublishNpmPackageDeployment1EsRelease
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies if I missed something during earlier discussion. How will the pipelines add git tags to the repo after releases in this new pattern?
steps: | ||
# Checkout the repository | ||
- checkout: self | ||
persistCredentials: true # Necessary for creation of git tags to work |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this job actually tag the repo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think tagging remains in the job that does it today (the deployment job that "becomes" a 1ES release job), this extra one wouldn't need this setting. But in https://github.com/microsoft/FluidFramework/pull/23913/files#r1968504949 I argue the new job probably isn't the right solution.
# This job is necessary to be compliant with 1ES. | ||
# 1ES does not allow checking out a code repo within a deployment job so instead we use this pattern | ||
# of checking out the repo in separate job and uploading it as a pipeline artifact. | ||
- job: checkoutAndUploadThisRepoAsArtifact | ||
steps: | ||
# Checkout the repository | ||
- checkout: self | ||
persistCredentials: true # Necessary for creation of git tags to work | ||
# Copy required files to the artifact staging directory | ||
- task: CopyFiles@2 | ||
inputs: | ||
SourceFolder: $(System.DefaultWorkingDirectory) | ||
Contents: '**/*' | ||
TargetFolder: $(Build.ArtifactStagingDirectory) | ||
# Publish the artifact containing the required files from the repository | ||
- task: 1ES.PublishPipelineArtifact@1 | ||
inputs: | ||
targetPath: $(Build.ArtifactStagingDirectory) | ||
artifactName: fluidFrameworkRepo | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm I think this would technically work, but still goes against the spirit of what we're trying to accomplish by complying with the 1ES suggestion, because we would still need to build the build-tools release group in the release job. That is ultimately what we're trying to not do: have to build any code in that job.
So in my mind, what we need to do is:
- From the build stage, publish the build output of the build-tools release group as an artifact.
- I don't remember if the current build stage also builds build-tools every time; I think it does it if the pipeline is run with the (default) setting to install/use build-tools from the repo. But we might need to ensure that always happens so we have the artifact available when publishing.
- In the release job, download that artifact and make the necessary updates to use it.
- I think instead of using
include-install-build-tools.yml
, which does all the building and linking of build-tools, we just grab a couple of pieces from that template, adjust them if needed, and use them directly (might just need thenpm link
line).
- I think instead of using
…to test/seanimam/updatePublishNpmPackageDeployment1EsRelease
Description
Updates include-publish-npm-package-deployment to be 1ES compliant.
The change moves the code checkout step to a separate job and uploads it as a pipeline artifact because 1ES compliant deployment jobs do not allow checking out a code repository.
Breaking Changes
Reviewer Guidance
templateContext
section?