Update build to use a local package cache from a submodule and build offline

[wtgodbe]

Replaces https://github.com/dotnet/aspnetcore/pull/53524/files to fix a casing issue with the submodule. Should fix #53710.

[wtgodbe]

@javiercn is this the right time to call npm cache verify (before Restore)?

[javiercn]

Yep

[MichaelSimons]

Wanted to get your thoughts on if this warrants validating in the VMR prior to merging? I would like to avoid surprises, regressing SB CI, and/or blocking the sdk->installer dependency flow.

[wtgodbe]

Wanted to get your thoughts on if this warrants validating in the VMR prior to merging? I would like to avoid surprises, regressing SB CI, and/or blocking the sdk->installer dependency flow.

I think that's a good idea. How can I help get that done?

[javiercn]

We also need to remove the checked in JS files, don't we?

[wtgodbe]

We also need to remove the checked in JS files, don't we?

Good point, doing that now

[javiercn]

@wtgodbe I'm merging this as I'm doing npm dependency updates as part of build ops and I don't want to create conflicts for you.

[MichaelSimons]

Wanted to get your thoughts on if this warrants validating in the VMR prior to merging? I would like to avoid surprises, regressing SB CI, and/or blocking the sdk->installer dependency flow.

I think that's a good idea. How can I help get that done?

I see this is already merged but for future reference, you can either create a git patch with your changes and apply it to the vmr or use this vmr-sync script. In this particular case involving the submodule, the vmr-sync would be the recommended approach. Once the changes are applied, I would recommend just opening a draft PR and let the CI run to validate. If you would like to build locally, the build instructions are in the VMR's readme

[MichaelSimons]

It would still be good to validate this IMO to ensure this does not block the sdk->installer dependency flow or regress source-build.

[MichaelSimons]

It would still be good to validate this IMO to ensure this does not block the sdk->installer dependency flow or regress source-build.

On another look, this won't affect source-build because BuildNodeJS is not set to true in SB. Is enabling this in source-build on someone's radar/tracked in an issue?

[mthalman]

This seems to be causing a failure: dotnet/installer#18641 (comment)

[wtgodbe]

Responded here: dotnet/installer#18641 (comment)

[wtgodbe]

On another look, this won't affect source-build because BuildNodeJS is not set to true in SB. Is enabling this in source-build on someone's radar/tracked in an issue?

It's already enabled in this repo's source-build leg. I'm enabling it in Installer in dotnet/installer#18641

[MichaelSimons]

This appears to have regressed all of the offline source-build legs in CI - dotnet/source-build#4129

[javiercn]

@MichaelSimons The error seems to be caused by a component that is likely not needed and that we can avoid using. Is there a way to setup an environment variable in source build?

We probably just need to set PUPPETEER_SKIP_DOWNLOAD=1 but I don't know if that's done here or in the source build config/definition.

[javiercn]

#54036