Skip to content

Attempt to auto-publish vs.redist packages to orchestrated feed #20211

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

Merged
merged 13 commits into from
Apr 1, 2020

Conversation

wtgodbe
Copy link
Member

@wtgodbe wtgodbe commented Mar 26, 2020

@wtgodbe wtgodbe requested review from dagood, Pilchie and a team March 26, 2020 21:26
@@ -276,6 +280,10 @@
ManifestArtifactData="NonShipping=true"
Condition="'%(PackageToPublish.Category)' != 'ship'" />

<PackageToPublishToTransport
Copy link
Member Author

Choose a reason for hiding this comment

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

PublishToTransportFeed is the target that runs when we're trying to publish to the orchestrated feed, so as long as I also update https://devdiv.visualstudio.com/DevDiv/_git/DotNet-Orchestration-Utilities?path=%2Fsrc%2FFinal.VSFeedPublish.targets&version=GBmaster, the orchestration should take care of copying the redist packages from the orchestrated feed to the VS feed

Copy link
Contributor

Choose a reason for hiding this comment

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

Another option would be to include these packages in @(FilesToPublish) i.e. changing the input GetFilesToPublish target. That has the advantage of placing the files in the \aspnetci drop too.

@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 26, 2020

This doesn't yet solve the issue of giving the vs.redist packages nonstable versions - working on that

Copy link
Member

@dagood dagood left a comment

Choose a reason for hiding this comment

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

Looks reasonable to me!

@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 26, 2020

I think this should also use non-stable versioning for the vs.redist package now without destabilizing anything else, but I'm not 100% sure because I haven't been able to successfully build locally yet 😆

Copy link
Contributor

@dougbu dougbu left a comment

Choose a reason for hiding this comment

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

Looks good modulo one typo. Fire up a build on TeamCity if you wanna test it out -- publish attempts shouldn't hurt anything.

@dougbu
Copy link
Contributor

dougbu commented Mar 26, 2020

run a test prodcon build of AspNetCore 2.1

Unless you've updated the TC configuration to skip publishing for non-ProdCon builds, any build should do. And, if you did change the configuration, can temporarily change it back to be unconditional 😃

@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 26, 2020

Unless you've updated the TC configuration to skip publishing for non-ProdCon builds, any build should do. And, if you did change the configuration, can temporarily change it back to be unconditional 😃

Don't I need to provide some variables that would normally come from orchestration (e.g. the key for https://dotnetfeed.blob.core.windows.net/orchestrated-release-2-1/ ?

@dougbu
Copy link
Contributor

dougbu commented Mar 26, 2020

Ah, you want to test to a later endpoint than I thought. I was just looking to see what the build tried to push.

@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 26, 2020

I was just looking to see what the build tried to push.

Well, that might be enough - I'll try queuing a team city build just in case

@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 26, 2020

I don't see a way to run a build against a custom branch in TeamCity 😦

@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 26, 2020

I could merge this then revert it, and run a build against the initial merge

@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 26, 2020

@JunTaoLuo helped me figure out how to change the branch, so I've got the build running now

@@ -276,6 +280,10 @@
ManifestArtifactData="NonShipping=true"
Condition="'%(PackageToPublish.Category)' != 'ship'" />

<PackageToPublishToTransport
Copy link
Contributor

Choose a reason for hiding this comment

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

Another option would be to include these packages in @(FilesToPublish) i.e. changing the input GetFilesToPublish target. That has the advantage of placing the files in the \aspnetci drop too.

- should trigger a build that's more likely to succeed
@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 27, 2020

The build succeeded, but didn't attempt to publish the redist packages because it didn't pass PublishType=blob (and therefore didn't run the PublishToTransportFeed target). I'll queue another one w/ that param

@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 27, 2020

Here's the Dotnet-Orchestration-Utilities PR, @dagood PTAL: https://devdiv.visualstudio.com/DevDiv/_git/DotNet-Orchestration-Utilities/pullrequest/238164?_a=overview

@Pilchie Pilchie added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label Mar 27, 2020
@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 27, 2020

Build failed before it could be informative because we didn't pass the account name or key for the orchestrated feed. Instead I'm gonna just print what we would try to publish in the next build (I'll undo 3a5b333 before merging)

@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 27, 2020

@dougbu I have some concern about using FilesToPublish because I believe not everything in that ItemGroup is winding up in the orchestrated feed. I'll confirm with the build I have running now

@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 27, 2020

Looks like the outage is impacting my val build 😢 hopefully it's fixed soon, or at least by monday

Copy link
Contributor

@JunTaoLuo JunTaoLuo left a comment

Choose a reason for hiding this comment

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

LGTM

@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 31, 2020

Not working yet, the redist packages aren't being included in PackageToPublishToTransport. Investigating why.

@wtgodbe
Copy link
Member Author

wtgodbe commented Mar 31, 2020

I merged https://devdiv.visualstudio.com/DevDiv/_git/DotNet-Orchestration-Utilities/pullrequest/238164?_a=overview

@@ -174,6 +175,10 @@
<PackageToPublish Include="%(_SymbolsPackageArtifactInfo.ArtifactPath)" Category="symbols" IsSymbolsPackage="true" />
</ItemGroup>

<ItemGroup>
<RedistPackageToPublish Include="$(DependencyAssetsDir)(SharedFrameworkRedistPackageId)*" />
Copy link
Member Author

Choose a reason for hiding this comment

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

Well don't I have an egg on my face... This isn't working because there's no '$' before (SharedFrameworkRedistPackageId) 🤦‍♂

@wtgodbe wtgodbe marked this pull request as ready for review April 1, 2020 16:30
@wtgodbe
Copy link
Member Author

wtgodbe commented Apr 1, 2020

Ok, this should be ready for review - the most recent TeamCity build confirmed it would attempt to publish the redist packages (w/ non-stable versions):

[17:28:04][Step 4/6] Publishing the following packages: D:\b\w\98f319efba687834/.deps\packages\Microsoft.AspNetCore.All.2.1.18.nupkg;D:\b\w\98f319efba687834/.deps\packages\Microsoft.AspNetCore.App.2.1.18.nupkg;D:\b\w\98f319efba687834/.deps\packages\Microsoft.DotNet.Web.Client.ItemTemplates.2.1.18.nupkg;D:\b\w\98f319efba687834/.deps\packages\Microsoft.DotNet.Web.ItemTemplates.2.1.18.nupkg;D:\b\w\98f319efba687834/.deps\packages\Microsoft.DotNet.Web.ProjectTemplates.2.1.2.1.18.nupkg;D:\b\w\98f319efba687834/.deps\packages\Microsoft.DotNet.Web.Spa.ProjectTemplates.2.1.2.1.18.nupkg;D:\b\w\98f319efba687834/.deps\packages\Microsoft.AspNetCore.Hosting.WebHostBuilderFactory.Sources.2.1.18.nupkg;D:\b\w\98f319efba687834/.deps\packages\Microsoft.AspNetCore.AspNetCoreModuleV1.2.1.18.nupkg;D:\b\w\98f319efba687834/.deps\packages\Microsoft.AspNetCore.AspNetCoreModuleV1.2.1.18.symbols.nupkg;D:\b\w\98f319efba687834/.deps\packages\runtime.win-x64.Microsoft.AspNetCore.All.2.1.18.symbols.nupkg;D:\b\w\98f319efba687834/.deps\packages\runtime.win-x64.Microsoft.AspNetCore.App.2.1.18.symbols.nupkg;D:\b\w\98f319efba687834/.deps\packages\runtime.win-x86.Microsoft.AspNetCore.All.2.1.18.symbols.nupkg;D:\b\w\98f319efba687834/.deps\packages\runtime.win-x86.Microsoft.AspNetCore.App.2.1.18.symbols.nupkg;D:\b\w\98f319efba687834/.deps\packages\runtime.linux-musl-x64.Microsoft.AspNetCore.All.2.1.18.symbols.nupkg;D:\b\w\98f319efba687834/.deps\packages\runtime.linux-musl-x64.Microsoft.AspNetCore.App.2.1.18.symbols.nupkg;D:\b\w\98f319efba687834/.deps\packages\runtime.linux-x64.Microsoft.AspNetCore.All.2.1.18.symbols.nupkg;D:\b\w\98f319efba687834/.deps\packages\runtime.linux-x64.Microsoft.AspNetCore.App.2.1.18.symbols.nupkg;D:\b\w\98f319efba687834.deps\assets\VS.Redist.Common.AspNetCore.SharedFramework.x64.2.1.2.1.18-servicing-31339.nupkg;D:\b\w\98f319efba687834.deps\assets\VS.Redist.Common.AspNetCore.SharedFramework.x86.2.1.2.1.18-servicing-31339.nupkg

@wtgodbe
Copy link
Member Author

wtgodbe commented Apr 1, 2020

@dougbu @JunTaoLuo any last concerns?

@wtgodbe
Copy link
Member Author

wtgodbe commented Apr 1, 2020

I believe I've reset everything in teamcity to the way it was (I only changed VCSBranches & IsFinalBuild), but it'd be great if you guys could take a glance at the project settings to see if it looks like I missed anything

@dougbu
Copy link
Contributor

dougbu commented Apr 1, 2020

it'd be great if you guys could take a glance at the project settings to see if it looks like I missed anything

You can double-check things too. Compare the public and private build configurations and confirm the only differences are obvious eg. related to signing.

Copy link
Contributor

@dougbu dougbu left a comment

Choose a reason for hiding this comment

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

Smallish bits to change before merging…

@wtgodbe
Copy link
Member Author

wtgodbe commented Apr 1, 2020

@dougbu I pushed a commit responding to your feedback

@wtgodbe
Copy link
Member Author

wtgodbe commented Apr 1, 2020

You can double-check things too. Compare the public and private build configurations and confirm the only differences are obvious eg. related to signing.

Doing that now

@wtgodbe wtgodbe merged commit d9c2f74 into release/2.1 Apr 1, 2020
@wtgodbe wtgodbe deleted the wtgodbe/AutoPublishRedist branch April 1, 2020 21:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants