Publish Microsoft.Dotnet.Insntallation library to NuGet feed #51575
Conversation
This makes it easier to run commands such as "dotnet pack" in the project folder
| - task: 1ES.PublishNuget@1 | ||
| displayName: 🟣 Publish packages to AzDO | ||
| inputs: | ||
| useDotNetTask: true |
There was a problem hiding this comment.
Something to note here, I don't think this will consume the .dotnet/dotnet, so that may have different behavior from the .NET 10 SDK we've used above. All this is doing is publish so I dont see it causing issues, but it may be confusing if we change publishing somehow in the major version of the SDK, and the rest of the build relies on latest while this relies on whatever the CI machine has (I think right now, it's .net 9.) Anyway I don't see this as a major issue.
There was a problem hiding this comment.
There's likely a setting to use a custom exe, most 1es tasks do have this.
| <PackagesDir Condition="'$(PackagesDir)' == ''">$(_RepoRoot)artifacts\packages\Release\</PackagesDir> | ||
| <IntermediateOutputPath Condition="'$(IntermediateOutputPath)' == ''">$(_RepoRoot)artifacts\obj\Sign\</IntermediateOutputPath> | ||
| <LogDir Condition="'$(LogDir)' == ''">$(_RepoRoot)artifacts\log\Sign\</LogDir> | ||
| <PackagesDir Condition="'$(PackagesDir)' == ''">$(RepoRoot)artifacts\packages\Release\</PackagesDir> |
| & .\.dotnet\dotnet build .\src\Installer\Microsoft.Dotnet.Installation\Microsoft.Dotnet.Installation.sign.proj /t:Sign | ||
| & .\.dotnet\dotnet build .\src\Installer\Installer.sign.proj /t:Sign -bl:$(Build.SourcesDirectory)/artifacts/binlogs/dnup-library-sign.binlog $(_officialBuildProperties) | ||
| displayName: 🖋️ Sign dnup library packages with arcade signtool | ||
| - task: 1ES.PublishNuget@1 |
There was a problem hiding this comment.
nit: In theory, I would prefer to keep publish as a separate task if we ever want to do a deployment.
In practice, that'd need to be a separate stage which relies on the package yml stage to finish. That means we'll need to wait for another machine to be available which adds delay. So, I'm happy with this in the long term for now too!
| <Title>.NET Installation Library</Title> | ||
| <Version>1.0.0-alpha</Version> | ||
| <PackageVersion Condition="'$(PackageVersion)'==''">$(Version)</PackageVersion> | ||
| <VersionPrefix>0.1.0</VersionPrefix> |
There was a problem hiding this comment.
What will happen when we try to publish a package with the version that's already been published, since we don't automatically update the build number per each PR? Does it just replace it?
There was a problem hiding this comment.
Arcade automatically adds the build number to the prerelease specifier if the package version isn't stabilized. For example, we end up with something like 0.1.0-preview.2.25555.2.
…es\templates\jobs\dnup as paths include if this enables on sdk runs
2 participants
Publish installation library package to dotnet-tools food during ci build.