-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Use new helix sdk/runtime functionality #31448
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
Conversation
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 bet correlation root is read only. Probably need to include just-built Microsoft.AspNetCore.App.Ref (if built) and Microsoft.AspNetCore.App.Runtime layouts in correlation payload for all platforms. Then, can exclude those packages from work item payloads.
Surprisingly all the tests are green, I'll run against the full helix matrix just to make sure there's no weirdness on any of the less used queues. |
.azure/pipelines/helix-matrix.yml
Outdated
@@ -1,5 +1,10 @@ | |||
# We only want to run full helix matrix on main | |||
pr: none | |||
pr: |
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.
remove
So its only the docker queues that seem to have read-only correlation directories, and its only the project template tests that likely need them there, seeing if there's a way to look for the template hive in a different directory |
Well everything is green now including helix matrix but I'm suspicious, @dougbu would we notice anything being broken immediately if the right aspnet runtime bits weren't installed for the template tests? |
I'm not sure. May only see problems after the templates (and their tests) are changed to take advantage of a runtime change. |
Should i just file an issue for that for now and get this change in since everything seems to be working? Its going to be hard for me to test whether anything I add works if the tests don't fail :/ |
Makes sense if you think adding the just-built Microsoft.AspNetCore.App.Runtime bits will be in the correlation payload before we something that breaks the template test. |
#31494 to track asp runtime bits potential issue |
@MattGal is there an easy way for me to see where a correlation payload got installed? So we still need to add our own correlation payload to install some aspnet runtime shared bits, I see the correlation payload in the logs, but it doesn't tell me where it gets installed to, and I don't see it in the right place. I verified that it has all the binaries we want, I was trying to get it installed alongside the new dotnet-cli payloads in: /home/helixbot/work/CB3D0A95/p/dotnet-cli/shared/Microsoft.AspNetCore.App/6.0.0-ci which I tried to do using Destination on the HelixCorrelationPayload here: aspnetcore/eng/helix/helix.proj Line 96 in f44abf5
|
It's true we don't log all the destination files (would bloat these logs quite a bit, the work item payload is bad enough) but you can easily figure this out by getting the job's list file (can get these URLs from the Helix API) Relevant bits are in every work item:
I'd guess one problem may be coming from having destination paths like Another common thing to do while developing and updating new work in Helix stuff would be to just recursively list the files in |
Yuck, so we need to set the destination path differently based on OS, or does windows handle '/' correctly? Do you have any advice for the best way for me to have this install into the cli payloads? Basically we just want to unpack this dll into a directory alongside the other correlation payloads (but inside) |
Or I guess I can package the zip to have the right sub structure and have it just go to dotnet-cli like the other payloads |
I think this is the better idea, but to your other question most (but not all) Windows APIs and consoles and such don't care about forward-slashes so you can often get away with only using /. |
@dougbu looks like the unit tests failures are due to the local aspnetcore.app directory not containing the data/RunTimeList.xml which is in the nupkg. I'm going to just switch back to unzipping the nupkgs for now since that was working immediately and actually took less lines of msbuild magic. I can file a followup issue for tracking if this is something that you think is worth changing in the future. |
This is where we specify the location of that file: aspnetcore/src/Framework/App.Runtime/src/Microsoft.AspNetCore.App.Runtime.csproj Lines 157 to 158 in 5ba5e56
it'll be available there after the SharedFx is built |
@wtgodbe so I tried building Microsoft.AspNetCore.App.Runtime and I don't see it get produced in the artifacts directory, or am I supposed to build a different directory to see it get dropped? |
Finally green again, @dougbu is there anything left that you want addressed in this iteration? I'll remove the helix matrix run now |
I'll review after lunch @HaoK |
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.
Mostly nits but please at least double-check the last comment I made.
<Copy SourceFiles="@(_appRuntimeFiles)" DestinationFolder="$(OutputPath)\AspNetCoreAppRuntimeHelix\shared\Microsoft.AspNetCore.App\$(SharedFxVersion)" /> | ||
<Unzip Condition="Exists('$(RepoRoot)artifacts\packages\$(Configuration)\Shipping\Microsoft.AspNetCore.App.Ref.$(SharedFxVersion).nupkg')" | ||
SourceFiles="$(RepoRoot)artifacts\packages\$(Configuration)\Shipping\Microsoft.AspNetCore.App.Ref.$(SharedFxVersion).nupkg" | ||
DestinationFolder="$(OutputPath)\AspNetCoreAppRuntimeHelix\packs\Microsoft.AspNetCore.App.Ref\$(SharedFxVersion)" /> |
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.
nit: Without the include list approach you took with the Runtime, this will include the .nuspec file, _rels folder, and package folder. Suggest doing a similar thing here but with $(RecursiveDir)
in the <Copy />
task to handle the multiple folders you do want in the Ref case.
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 it hurt to include those files? This mimics what we were doing before anyways, we used to just unzip everything into the folder in the test runner so I'd rather not tweak things any if its harmless for verification purposes. My preference would be to just use unzip for both of these, but the runtime tests are currently written to expect a flattened hierarchy where the RuntimeList.xml isn't in the package folder. Since the main purpose of this PR is to just get us switched onto the correlation payload functionality, I don't want to mess around with the app unit tests anymore since everything is passing. I can file an issue to clean up this area for tracking purposes if you feel this is important in the future, but I don't want to tweak the msbuild anymore in this PR
Co-authored-by: Doug Bunting <6431421+dougbu@users.noreply.github.com>
No description provided.