Installing v8 from blob storage #412
Conversation
ghost
added
the
|
It'd be nice if we could avoid defining a custom script file here, particularly one which has a dependency on Arcade's native toolset backend. Is there a way that the https://github.com/dotnet/arcade/blob/master/eng/common/init-tools-native.sh file, or some other Arcade file, could be used to explicitly install a known tool rather than the script relying on a |
|
I think we could also pull directly from https://storage.googleapis.com/chromium-v8/official/canary/v8-linux64-rel-8.5.183.zip instead of the arcade blob storage. The reason why we didn't do that in the Helix script was to avoid hitting Google's servers every time a new Helix machine is provisioned. Since the Docker image is rebuilt only once in a while this shouldn't be an issue here. We could also inline the linux-v8-engine.sh into the Dockerfile and remove the argument validation (we'll never call it with wrong values anyway) to shrink it. |
|
So I opted instead to inline the parts of the script that mattered (removed all parameter validation). I'm still not downloading it from Google's servers as @akoeplinger suggested above, since these will still be built every CI run and we wouldn't want to break CI if google servers are down. |
|
Merging to unblock dotnet/runtime#48429 |
3 participants
cc: @mthalman @akoeplinger
On the previous PR we were installing v8 engine from npm and jsvu whcih had the potential issue of failing to install npm which was being installed from a external script. This will switch to instead install it from blob storage and mimic the same way we do it for our helix queues, with the added benefit that engines won't be installed under /root/.jsvu meaning v8 will now be able to be ran by our trimming tests which is not working today.