Open omajid opened 1 year ago
@crummel
Getting a binlog would help - you could dotnet build
the failing .npmproj with the /p:ArcadeBuildFromSource=true
arg + /bl
. That would show you if/when PackageVersion
is being set.
Here's the full binlog: sourcebuild.binlog.tar.gz from a failing build of aspnetcore.
Building the individual project doesn't reproduce the issue :/
Looks like none of our .npmproj's have PackageVersion
set in that binlog, I think because they're not importing this file: https://github.com/dotnet/arcade/blob/main/src/Microsoft.DotNet.Arcade.Sdk/tools/Version.BeforeCommonTargets.targets. Trying to figure out why.
Could you also send a binlog of just building the .npmproj successfully (w/ the sourceBuild arg passed)? That could be informative on what isn't happening in the failing case.
I have a feeling I am using source-build args here incorrectly, but this is the binlog I get from:
$ cd aspnetcore
$ ./eng/build.sh --ci --configuration Release --restore --build --pack /p:ArcadeBuildFromSource=true # fails, as expected
$ cd artifacts/source-build/self/src/src/JSInterop/Microsoft.JSInterop.JS/src/
$ ../../../../.dotnet/dotnet msbuild /t:Pack /p:ArcadeBuildFromSource=true /bl:isolated-Microsoft.JSInterop.JS-working.binlog
@omajid where did you get ./eng/build.sh --ci --configuration Release --restore --build --pack /p:ArcadeBuildFromSource=true
from? I'm wondering why that fails but our CI source-build leg doesn't.
It's essentially the configuration used by source-build/VMR when building aspnetcore. You can see the full command line here: https://dev.azure.com/dnceng-public/public/_build/results?buildId=154293&view=logs&j=61a52f3a-cec1-5bff-8c02-d8ba2c8bed99&t=53e46d9d-cfbd-5072-889d-e51560a71252&l=2722:
/vmr/src/aspnetcore/eng/build.sh --ci --configuration Release --restore --build --pack -bl /p:ArcadeBuildFromSource=true /p:CopyWipIntoInnerSourceBuildRepo=true /p:DotNetBuildOffline=true /p:CopySrcInsteadOfClone=true /p:DotNetPackageVersionPropsPath="/vmr/artifacts/obj/x64/Release/PackageVersions.aspnetcore.props" /p:AdditionalSourceBuiltNupkgCacheDir="/vmr/artifacts/obj/x64/Release/blob-feed/packages/" /p:ReferencePackageNupkgCacheDir="/vmr/prereqs/packages/reference/" /p:PreviouslySourceBuiltNupkgCacheDir="/vmr/prereqs/packages/previously-source-built/" /p:SourceBuildUseMonoRuntime= --arch x64 --no-build-repo-tasks --no-build-nodejs /p:PublishCompressedFilesPathPrefix=/vmr/artifacts/obj/x64/Release/blobs/aspnetcore/Runtime/ /p:PortableBuild=false /p:TargetRuntimeIdentifier=centos.8-x64 /p:MicrosoftNetFrameworkReferenceAssembliesVersion=1.0.0 /p:DotNetPackageVersionPropsPath=/vmr/artifacts/obj/x64/Release/PackageVersions.aspnetcore.props
Oh, and the reason the CI leg doesn't fail is probably because of --no-build-nodejs
. That's present in the CI leg and the current full source-build VMR command. But it's missing in my run command.
I have removed it intentionally to test what building the VMR post https://github.com/dotnet/aspnetcore/pull/45883/ might look like.
There's some additional context at https://github.com/dotnet/source-build/discussions/3107 if you are interested.
Funny enough, this seems to build:
./eng/build.sh --ci --configuration Release --restore --build --pack /p:ArcadeBuildFromSource=true /p:ArcadeInnerBuildFromSource=true
The /p:ArcadeInnerBuildFromSource=true
is used to indicate this is the inner build. I think I am doing something wrong, though, because that's supposed to happen as part of the regular source-build anyway and should be identical (aside from different paths) to the main build.
[SB Triage] @crummel - can you please help investigate?
I think we should probably delay this investigation until after the planned yarn to npm switch if that sounds okay @omajid. @wtgodbe is there an issue for that? I wasn't able to find one.
Ah, the issue is a pretty long-standing one, I was looking for something new. it's https://github.com/dotnet/aspnetcore/issues/37398.
@crummel sure, that sounds okay. I hope this issue doesn't get auto-closed again :)
Is there an existing issue for this?
Describe the bug
(This is a follow up from https://github.com/dotnet/aspnetcore/issues/42378 which is now locked. Sorry about dropping the ball on that.)
When building ASP.NET Core, turning on source-build mode makes the build fail when it's trying to build nodejs projects
I am currently testing with aspnetcore commit
9ffffa45789328985d43cc70a378fd8570988f27
, but based on the issue linked above, the bug has existed for a while now.This works:
This fails:
The build failure looks like this:
This didn't seem a too big of a problem back when https://github.com/dotnet/aspnetcore/issues/42378 was opened, but with https://github.com/dotnet/aspnetcore/pull/45883/, this issue makes the build break with the VMR.
From what I can tell,
PackageVersion
is set to empty here:https://github.com/dotnet/aspnetcore/blob/ea683686bfac765690cb6e40f6ba7198cae26e65/eng/targets/Npm.Common.targets#L108
And that makes the
yarn
command fail.I don't know why
PackageVersion
is empty. I know that arcade handles${FOO}PackageVersion
specially forPackageVersions.props
. Could that be settingPackageVersion
to empty too? Is there some way I can track what's settingPackageVersion
to empty (or perhaps, not setting to the right version it when it should be set)?cc
@chrisrummel@dougbu @mthalman @michaelsimons @wtgodbeExpected Behavior
No response
Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version
No response
Anything else?
No response