daml/ci/compatibility-windows.yml

# Copyright (c) 2024 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
# SPDX-License-Identifier: Apache-2.0

parameters:
  - name: test_flags
    type: string
    default: ''

steps:
  - bash: ci/configure-bazel.sh
    displayName: 'Configure Bazel for root workspace'
    env:
      IS_FORK: $(System.PullRequest.IsFork)
      # to upload to the bazel cache
      GOOGLE_APPLICATION_CREDENTIALS_CONTENT: $(GOOGLE_APPLICATION_CREDENTIALS_CONTENT)
  - bash: ci/configure-bazel.sh
    displayName: 'Configure Bazel for compatibility workspace'
    env:
      BAZEL_CONFIG_DIR: compatibility
      IS_FORK: $(System.PullRequest.IsFork)
      # to upload to the bazel cache
      GOOGLE_APPLICATION_CREDENTIALS_CONTENT: $(GOOGLE_APPLICATION_CREDENTIALS_CONTENT)
  - task: DownloadPipelineArtifact@0
    inputs:
      artifactName: 'typescript-libs'
      targetPath: $(Build.SourcesDirectory)/sdk/compatibility/head_sdk
  - powershell: '.\sdk\compatibility\build-release-artifacts-windows.ps1'
    displayName: 'Build release artifacts'
  - powershell: '.\sdk\compatibility\test-windows.ps1  ${{ parameters.test_flags }}'
    displayName: 'Run tests'
update copyright (#18167) * update copyright * undo hack from #18168 * update hash in platform-independence-pre-check 2024-01-15 22:27:42 +03:00			`# Copyright (c) 2024 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.`
Make compat tests work on windows (#5732) * Make compat tests work on windows This required some changes to the daml_sdk rule since the read-only installation by the assistant breaks Bazel completely. We could only apply those changes on Windows but I think I prefer the consistency across platforms here over trying to stay close to how the SDK is installed on user machines given that the SDK installation is not something we’ve had issues with. I’ve excluded the postgresql tests for now. I don’t expect them to be particularly hard to fix but I’ve already spent almost 2 days on this and having some tests run on Windows seems like a clear improvement over running no tests on Windows :) changelog_begin changelog_end * Remove todo changelog_begin changelog_end 2020-04-28 17:06:36 +03:00			`# SPDX-License-Identifier: Apache-2.0`

			`parameters:`
			`- name: test_flags`
			`type: string`
			`default: ''`

			`steps:`
			`- bash: ci/configure-bazel.sh`
			`displayName: 'Configure Bazel for root workspace'`
			`env:`
			`IS_FORK: $(System.PullRequest.IsFork)`
			`# to upload to the bazel cache`
			`GOOGLE_APPLICATION_CREDENTIALS_CONTENT: $(GOOGLE_APPLICATION_CREDENTIALS_CONTENT)`
			`- bash: ci/configure-bazel.sh`
			`displayName: 'Configure Bazel for compatibility workspace'`
			`env:`
			`BAZEL_CONFIG_DIR: compatibility`
			`IS_FORK: $(System.PullRequest.IsFork)`
			`# to upload to the bazel cache`
			`GOOGLE_APPLICATION_CREDENTIALS_CONTENT: $(GOOGLE_APPLICATION_CREDENTIALS_CONTENT)`
Include create-daml-app tests in compatibility tests (#5945) This is the first part of #5700 It adds tests that build create-daml-app using `daml build` and then run the codegen and build the UI. Contrary to our main tests these also run on Windows. This is actually reasonably simple by first building the typescript libraries on Linux and then downloading them on Windows. There are two parts that are still missing from the tests in the main workspace: 1. Building the extra feature. This should be fairly easy to add. 2. Running the pupeeter tests. At least MacOS and Linux should be reasonably easy. I don’t know what horrors Windows will throw at us. This step is what actually makes this a compatibility test. Currently it doesn’t actually launch Sandbox and the JSON API. Since this PR is already pretty large, I’d like to tackle those things separately. changelog_begin changelog_end 2020-05-13 11:39:51 +03:00			`- task: DownloadPipelineArtifact@0`
			`inputs:`
			`artifactName: 'typescript-libs'`
move to subdir 3.0 (#18520) * move most files * update CI configuration 2024-03-22 04:27:46 +03:00			`targetPath: $(Build.SourcesDirectory)/sdk/compatibility/head_sdk`
			`- powershell: '.\sdk\compatibility\build-release-artifacts-windows.ps1'`
Make compat tests work on windows (#5732) * Make compat tests work on windows This required some changes to the daml_sdk rule since the read-only installation by the assistant breaks Bazel completely. We could only apply those changes on Windows but I think I prefer the consistency across platforms here over trying to stay close to how the SDK is installed on user machines given that the SDK installation is not something we’ve had issues with. I’ve excluded the postgresql tests for now. I don’t expect them to be particularly hard to fix but I’ve already spent almost 2 days on this and having some tests run on Windows seems like a clear improvement over running no tests on Windows :) changelog_begin changelog_end * Remove todo changelog_begin changelog_end 2020-04-28 17:06:36 +03:00			`displayName: 'Build release artifacts'`
move to subdir 3.0 (#18520) * move most files * update CI configuration 2024-03-22 04:27:46 +03:00			`- powershell: '.\sdk\compatibility\test-windows.ps1 ${{ parameters.test_flags }}'`
Make compat tests work on windows (#5732) * Make compat tests work on windows This required some changes to the daml_sdk rule since the read-only installation by the assistant breaks Bazel completely. We could only apply those changes on Windows but I think I prefer the consistency across platforms here over trying to stay close to how the SDK is installed on user machines given that the SDK installation is not something we’ve had issues with. I’ve excluded the postgresql tests for now. I don’t expect them to be particularly hard to fix but I’ve already spent almost 2 days on this and having some tests run on Windows seems like a clear improvement over running no tests on Windows :) changelog_begin changelog_end * Remove todo changelog_begin changelog_end 2020-04-28 17:06:36 +03:00			`displayName: 'Run tests'`