daml/compatibility/test-windows.ps1

53 lines
1.8 KiB
PowerShell
Raw Normal View History

Set-StrictMode -Version latest
$ErrorActionPreference = 'Stop'
# Copyright (c) 2021 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
# SPDX-License-Identifier: Apache-2.0
# Build the release artifacts required for running the compatibility
# tests against HEAD. At the moment this includes the SDK release tarball
# and the ledger-api-test-tool fat JAR.
Add `platform-version` field to `daml.yaml` (#6736) * Add `platform-version` field to `daml.yaml` This PR adds the `platform-version` field to `daml.yaml`. Based on the approach agreed upon in #6558, the logic for this all sits in `daml-helper` and there are no changes to the assistant. The details of how the logic work are in a comment so I’m not going to repeat them here but the commands that are affected are: - `daml sandbox` - `daml sandbox-classic` - `daml json-api` - `daml start` (but only for sandbox and the JSON API, not for Navigator or anything else) For tests, I’ve added a test to the compat workspace that installs two SDKs simultaneously and tries out various combinations and verifies that we get the correct version. Open to other ideas for testing this but that seemed like the most sensible option that actually tests what we run. changelog_begin - [DAML Assistant] You can now specify the version of Sandbox and the JSON API independently of your SDK version by setting ``platform-version`` in your ``daml.yaml``. This is useful if you are deploying to a ledger that is running components from a different SDK version. See https://docs.daml.com/tools/assistant.html#project-config-file-daml-yaml for details. changelog_end * Run platform-version tests changelog_begin changelog_end * Fix tag globbing changelog_begin changelog_end * fmt changelog_begin changelog_end * . changelog_begin changelog_end * Try to fix env vars changelog_begin changelog_end * Remove hardcoded references to 1.2.0 changelog_begin changelog_end * Rephrase doc comment changelog_begin changelog_end * get things to compile changelog_begin changelog_end * maybe fix things for realz changelog_begin changelog_end * Remove debugging output changelog_begin changelog_end * Get angry at windows changelog_begin changelog_end * why is windows changelog_begin changelog_end * . changelog_begin changelog_end
2020-07-15 17:30:01 +03:00
$test_args = ""
if (($args.length -ge 1) -and ($args[0] -eq "--quick")) {
Add `platform-version` field to `daml.yaml` (#6736) * Add `platform-version` field to `daml.yaml` This PR adds the `platform-version` field to `daml.yaml`. Based on the approach agreed upon in #6558, the logic for this all sits in `daml-helper` and there are no changes to the assistant. The details of how the logic work are in a comment so I’m not going to repeat them here but the commands that are affected are: - `daml sandbox` - `daml sandbox-classic` - `daml json-api` - `daml start` (but only for sandbox and the JSON API, not for Navigator or anything else) For tests, I’ve added a test to the compat workspace that installs two SDKs simultaneously and tries out various combinations and verifies that we get the correct version. Open to other ideas for testing this but that seemed like the most sensible option that actually tests what we run. changelog_begin - [DAML Assistant] You can now specify the version of Sandbox and the JSON API independently of your SDK version by setting ``platform-version`` in your ``daml.yaml``. This is useful if you are deploying to a ledger that is running components from a different SDK version. See https://docs.daml.com/tools/assistant.html#project-config-file-daml-yaml for details. changelog_end * Run platform-version tests changelog_begin changelog_end * Fix tag globbing changelog_begin changelog_end * fmt changelog_begin changelog_end * . changelog_begin changelog_end * Try to fix env vars changelog_begin changelog_end * Remove hardcoded references to 1.2.0 changelog_begin changelog_end * Rephrase doc comment changelog_begin changelog_end * get things to compile changelog_begin changelog_end * maybe fix things for realz changelog_begin changelog_end * Remove debugging output changelog_begin changelog_end * Get angry at windows changelog_begin changelog_end * why is windows changelog_begin changelog_end * . changelog_begin changelog_end
2020-07-15 17:30:01 +03:00
$test_args = "--test_tag_filters=+head-quick"
}
write-output $test_args
# For reasons I do not understand, it seems to be important
# to sync here even though we sync in the previous step already.
.\dev-env\windows\bin\dadew.ps1 sync
.\dev-env\windows\bin\dadew.ps1 enable
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
}
# This is currently shared between various powershell scripts.
# We should probably factor this out.
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)"
}
cd compatibility
# Symlinks dont work on Windows.
cp ../.bazelrc .bazelrc
bazel shutdown
bazel fetch @nodejs_dev_env//...
bazel build //...
bazel shutdown
Add `platform-version` field to `daml.yaml` (#6736) * Add `platform-version` field to `daml.yaml` This PR adds the `platform-version` field to `daml.yaml`. Based on the approach agreed upon in #6558, the logic for this all sits in `daml-helper` and there are no changes to the assistant. The details of how the logic work are in a comment so I’m not going to repeat them here but the commands that are affected are: - `daml sandbox` - `daml sandbox-classic` - `daml json-api` - `daml start` (but only for sandbox and the JSON API, not for Navigator or anything else) For tests, I’ve added a test to the compat workspace that installs two SDKs simultaneously and tries out various combinations and verifies that we get the correct version. Open to other ideas for testing this but that seemed like the most sensible option that actually tests what we run. changelog_begin - [DAML Assistant] You can now specify the version of Sandbox and the JSON API independently of your SDK version by setting ``platform-version`` in your ``daml.yaml``. This is useful if you are deploying to a ledger that is running components from a different SDK version. See https://docs.daml.com/tools/assistant.html#project-config-file-daml-yaml for details. changelog_end * Run platform-version tests changelog_begin changelog_end * Fix tag globbing changelog_begin changelog_end * fmt changelog_begin changelog_end * . changelog_begin changelog_end * Try to fix env vars changelog_begin changelog_end * Remove hardcoded references to 1.2.0 changelog_begin changelog_end * Rephrase doc comment changelog_begin changelog_end * get things to compile changelog_begin changelog_end * maybe fix things for realz changelog_begin changelog_end * Remove debugging output changelog_begin changelog_end * Get angry at windows changelog_begin changelog_end * why is windows changelog_begin changelog_end * . changelog_begin changelog_end
2020-07-15 17:30:01 +03:00
bazel test //... $test_args