mirror of
https://github.com/digital-asset/daml.git
synced 2024-11-10 10:46:11 +03:00
433f484188
They can weigh close to 1GB, and the internal Azure networks are
unreliable enough that this adds up significant amounts of time to our
already slow CI pipeline (usually around a minute, but I've seen at
least one case where it took almost 28 minutes).
Given that we pretty much never look a them, 🔥.
CHANGELOG_BEGIN
CHANGELOG_END
58 lines
2.2 KiB
PowerShell
58 lines
2.2 KiB
PowerShell
Set-StrictMode -Version latest
|
||
$ErrorActionPreference = 'Stop'
|
||
|
||
.\dev-env\windows\bin\dadew.ps1 install
|
||
.\dev-env\windows\bin\dadew.ps1 sync
|
||
.\dev-env\windows\bin\dadew.ps1 enable
|
||
|
||
if (!(Test-Path .\.bazelrc.local)) {
|
||
Set-Content -Path .\.bazelrc.local -Value 'build --config windows'
|
||
}
|
||
|
||
$ARTIFACT_DIRS = if ("$env:BUILD_ARTIFACTSTAGINGDIRECTORY") { $env:BUILD_ARTIFACTSTAGINGDIRECTORY } else { Get-Location }
|
||
|
||
# If a previous build was forcefully terminated, then stack's lock file might
|
||
# not have been cleaned up properly leading to errors of the form
|
||
#
|
||
# user error (hTryLock: lock already exists: C:\Users\VssAdministrator\AppData\Roaming\stack\pantry\hackage\hackage-security-lock)
|
||
#
|
||
# The package cache might be corrupted and just removing the lock might lead to
|
||
# errors as below, so we just nuke the entire stack cache.
|
||
#
|
||
# Failed populating package index cache
|
||
# IncompletePayload 56726464 844
|
||
#
|
||
if (Test-Path -Path $env:appdata\stack\pantry\hackage\hackage-security-lock) {
|
||
Write-Output ">> Nuking stack directory"
|
||
Remove-Item -ErrorAction Continue -Force -Recurse -Path $env:appdata\stack
|
||
}
|
||
|
||
function bazel() {
|
||
Write-Output ">> bazel $args"
|
||
$global:lastexitcode = 0
|
||
$backupErrorActionPreference = $script:ErrorActionPreference
|
||
$script:ErrorActionPreference = "Continue"
|
||
& bazel.exe @args 2>&1 | %{ "$_" }
|
||
$script:ErrorActionPreference = $backupErrorActionPreference
|
||
if ($global:lastexitcode -ne 0 -And $args[0] -ne "shutdown") {
|
||
Write-Output "<< bazel $args (failed, exit code: $global:lastexitcode)"
|
||
throw ("Bazel returned non-zero exit code: $global:lastexitcode")
|
||
}
|
||
Write-Output "<< bazel $args (ok)"
|
||
}
|
||
|
||
# ScalaCInvoker, a Bazel worker, created by rules_scala opens some of the bazel execroot's files,
|
||
# which later causes issues on Bazel init (source forest creation) on Windows. A shutdown closes workers,
|
||
# which is a workaround for this problem.
|
||
bazel shutdown
|
||
|
||
# Prefetch nodejs_dev_env to avoid permission denied errors on external/nodejs_dev_env/nodejs_dev_env/node.exe
|
||
# It isn’t clear where exactly those errors are coming from.
|
||
bazel fetch @nodejs_dev_env//...
|
||
|
||
bazel build //...
|
||
|
||
bazel shutdown
|
||
|
||
bazel test `-`-experimental_execution_log_file ${ARTIFACT_DIRS}/test_execution_windows.log //...
|