Rename iOS-sim to iOSSimulator, #93
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
steveisok
approved these changes
Mar 17, 2021
directhex
pushed a commit
that referenced
this pull request
May 13, 2022
This change modifies the MS-ICU Nuget build pipeline to use ESRP Code Signing instead of PackageES Code Signing. Finally, after various delays and setbacks, we are now able to migrate to using ESRP Code Signing for the MS-ICU Nuget. This PR changes the Nuget build pipeline to use the ESRP Code Signing instead of the deprecated PackageES Code Signing. The end result in terms of the output signed binaries and packages is the same, but the mechanism is now different. I did a test build of the pipeline and doubled-checked the output, and the DLLs are signed with the same certificate: CN = Microsoft Code Signing PCA 2011 The Nuget packages are signed with the same certificate as well. Subject Name: CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US Issued by: CN=DigiCert SHA2 Assured ID Code Signing CA, OU=www.digicert.com, O=DigiCert Inc, C=US The ESRP process signs the DLLs and packages in-place, rather than outputting them to a separate folder, so I also had to slightly modify the Nuget build script in order to not look for the "signed" folder anymore. Note: This change also migrates us off the PackageES lab and uses the public Azure Pipelines for all stages now.
directhex
pushed a commit
that referenced
this pull request
May 13, 2022
Since the Nuget creation and Nuget code signing are now done as two separate stages in the build pipeline, the Windows symbols publishing task fails as it relied on the DownloadBuildArtifacts tasks in the Nuget creation step. (This was missed in the refactoring of the pipeline in PR #93.) However, since the Nuget doesn't contain any symbols at all, we can move the DownloadBuildArtifacts tasks entirely to the Nuget code signing stage instead. Also, it turns out that the PublishSymbols task cannot run on the public Azure Pipelines pool and must be run on the PackageES pool. (Note: I skipped the actual publish step when testing PR #93, as you can't unpublish things once published. However, when running the Release Pipeline to publish for real, it errors out.) Note: FWIW, the ProjectReunion pipeline also uses the PackageES lab for publishing symbols as well here: https://github.com/microsoft/ProjectReunion/blob/1714557cad5e740c0153e451fbf0311c8e5bdfc1/build/ProjectReunion-BuildFoundation.yml#L172-L188
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See discussion on dotnet/runtime#49305