mirror of
https://github.com/digital-asset/daml.git
synced 2024-09-20 09:17:43 +03:00
7c83265ef9
When we build a release, it is always a "past" commit - typically, one that has already been tested twice: once when the corresponding PR was run, and then again as a "main"-branch commit. Release branches don't run, but their protection rules enforce linear merges. Either way, we know we're building a _good_ commit, and, assuming our builds and tests are hermetic, testing that commit again when we make a release is a pure waste of time and CPU resources. The other case, where we make an ad-hoc release from a branch that has not been merged, has a similar issue: we do not necessarily want to run the full test suite, because part of the reason we need that commit may be that it doesn't succeed as is. Based on that observation, I wondered what might be the minimal set of things we actually need to build when making a release. This PR is an experiment in trying to find that out.
72 lines
2.7 KiB
PowerShell
72 lines
2.7 KiB
PowerShell
Set-StrictMode -Version latest
|
||
$ErrorActionPreference = 'Stop'
|
||
|
||
# See https://github.com/lukesampson/scoop/issues/3859
|
||
Set-Strictmode -Off
|
||
.\dev-env\windows\bin\dadew.ps1 install
|
||
Set-StrictMode -Version latest
|
||
.\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 (!(Test-Path ${ARTIFACT_DIRS}/logs)) {
|
||
mkdir -p ${ARTIFACT_DIRS}/logs
|
||
} elseif (Test-Path ${ARTIFACT_DIRS}/logs -PathType Leaf) {
|
||
throw ("Cannot create directory '${ARTIFACT_DIRS}/logs'. Conflicting file.")
|
||
}
|
||
|
||
# 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\u\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 `
|
||
//compiler/damlc/tests:platform-independence.dar `
|
||
//release:sdk-release-tarball-ce `
|
||
//release:sdk-release-tarball-ee `
|
||
`-`-profile build-profile.json `
|
||
`-`-experimental_profile_include_target_label `
|
||
`-`-build_event_json_file build-events.json `
|
||
`-`-build_event_publish_all_actions
|
||
|
||
bazel shutdown
|