mirror of
https://github.com/digital-asset/daml.git
synced 2024-09-20 01:07:18 +03:00
979e12fa68
* Move artifact publishing out of yaml files The current publishing process pretty much hardcodes the set of artifacts we publish in the yaml config. This is a problem because we always release from `main` so the yaml files are always identical. However, we will add new artifacts over time and this starts falling apart. This PR changes this such that the process described in the yaml files is very generic and just uploads and downloads everything in a directory whereas the details are handled in bash scripts that will come from the respective release branch and are therefore version-dependent. As usual for these type of changes, I don’t have a great way to test this. I did do some due diligence to test that at least the artifacts are published correctly and I can download them but I can’t test the actual publishing. changelog_begin changelog_end * Update ci/copy-unix-release-artifacts.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> * Update ci/copy-windows-release-artifacts.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> * Update ci/publish-artifactory.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
63 lines
2.4 KiB
PowerShell
63 lines
2.4 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 }
|
||
|
||
mkdir -p ${ARTIFACT_DIRS}/logs
|
||
|
||
# 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 `-`-experimental_execution_log_file ${ARTIFACT_DIRS}/logs/build_execution_windows.log //...
|
||
|
||
bazel shutdown
|
||
|
||
bazel test `-`-experimental_execution_log_file ${ARTIFACT_DIRS}/logs/test_execution_windows.log //...
|