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

[ci] Simplify shipping drop metadata names #9181

Merged
merged 1 commit into from
Aug 12, 2024
Merged

Conversation

pjcollins
Copy link
Member

Using the $(System.JobAttempt) variable in the drop metadata artifact
name is problematic. In some cases the drop artifacts created by the
nuget-msi-convert job will be used by a different job, and the job
attempt number will not necessarily match if any jobs are re-ran.

Using the $(System.JobAttempt) variable in the drop metadata artifact
name is problematic. In some cases the drop artifacts created by the
nuget-msi-convert job will be used by a different job, and the job
attempt number will not necessarily match if any jobs are re-ran.
@pjcollins pjcollins requested a review from jonpryor as a code owner August 8, 2024 14:25
@pjcollins pjcollins merged commit d050fda into main Aug 12, 2024
55 of 58 checks passed
@pjcollins pjcollins deleted the dev/pjc/dropmetarename branch August 12, 2024 18:57
jonathanpeppers pushed a commit that referenced this pull request Aug 13, 2024
Using the $(System.JobAttempt) variable in the drop metadata artifact
name is problematic. In some cases the drop artifacts created by the
nuget-msi-convert job will be used by a different job, and the job
attempt number will not necessarily match if any jobs are re-ran.
pjcollins added a commit that referenced this pull request Aug 15, 2024
Using the $(System.JobAttempt) variable in the drop metadata artifact
name is problematic. In some cases the drop artifacts created by the
nuget-msi-convert job will be used by a different job, and the job
attempt number will not necessarily match if any jobs are re-ran.
pjcollins added a commit that referenced this pull request Aug 16, 2024
…ts (#9195)

* [ci] Improve maestro artifact publishing (#8945)

Context: https://github.com/dotnet/arcade/blob/efc3da96e5ac110513e92ebd9ef87c73f44d8540/Documentation/DependencyFlowOnboardingWithoutArcade.md

The steps used to publish build asset information to maestro have been
updated.

With the new `PushToAzureDevOpsArtifacts` task the build pipeline should
now create all of the artifacts required for maestro artifact publishing.
The `add-build-to-channel` darc command will now trigger a
[Build Promotion Pipeline][0] that pushes build assets to the feed that
corresponds to the maestro channel that is being updated.  We should
no longer need to push assets to various NuGet feeds in a separate step.

[0]: https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=9577012&view=logs&j=ba23343f-f710-5af9-782d-5bd26b102304&t=c7a8693b-2f9c-5ea8-c909-cde9405ac2e1&l=238

* [ci] Use long version for maestro publishing (#8964)

Commit bbac9fe ran into some issues when attempting to publish to maestro:

    error : Asset 'D:\a\_work\1\a\7dc04dfe-406a-4fa3-aea0-199acc2763fa\MergedManifest.xml' already exists with different contents at assets/manifests/xamarin-xamarin-android/34.99.0-dev/MergedManifest.xml

We should be able to fix this by using the long package version which
optionally includes pre-release labeling and commit distance info.

* [ci] Use drop service for SDK insertion artifacts  (#9116)

Context: xamarin/yaml-templates@8759ec9
Context: xamarin/sdk-insertions#149

Steps to upload release artifacts to custom blob storage have been
replaced with azure-artifacts-drop (aka.ms/drop).

A new version of nuget-msi-convert has been added that will create a set
of artifact drops for the following shipping artifacts:
  * nugets
  * vs-components
  * vs-packs

The nugets drop contains all shipping packages that should be pushed to
various feeds or NuGet.org.

The components and packs drops are used for VS insertions.

* [ci] Fix maestro publishing for stable packages (#9118)

We've seen the build promotion pipeline fail when trying to publish
stable package versions:

    error : Package 'Microsoft.iOS.Ref.net8.0_17.5' has stable version '17.5.8001' but is targeted at a non-isolated feed 'https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet8/nuget/v3/index.json'

This is because we were not declaring these packages as stable when
building the build asset registry manifest.

Fix this by passing the `$(IsStableBuild)` property to the build asset
manifest creation task. This property needs to be updated manually when
switching to stable package versioning (see commit 4ea5dbb).

When `$(IsStableBuild)` is set to true, packages will be pushed to an
isolated feed during publishing, such as:

      Package [email protected] (Shipping) should go to https://pkgs.dev.azure.com/dnceng/public/_packaging/darc-pub-dotnet-android-b8317b6f/nuget/v3/index.json (Isolated, Public)

* [ci] Use passwordless auth for darc/maestro (#9182)

Fixes: #9164

Migrates darc/maestro commands to use a passwordless auth flow, as token
based authentication is deprecated and will be removed in the future.

* Use net8.0 version of Microsoft.DotNet.SharedFramework.Sdk

* [ci] Simplify shipping drop metadata names (#9181)

Using the $(System.JobAttempt) variable in the drop metadata artifact
name is problematic. In some cases the drop artifacts created by the
nuget-msi-convert job will be used by a different job, and the job
attempt number will not necessarily match if any jobs are re-ran.
@github-actions github-actions bot locked and limited conversation to collaborators Sep 12, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants