digital-asset/daml
1
1
Fork 0
mirror of https://github.com/digital-asset/daml.git synced 2024-09-19 00:37:23 +03:00
Code Issues Projects Releases Wiki Activity
8e905b34c0
daml/compatibility
History
Stephen Compall 664a0c0076
add Action to high-level trigger updateState (#7621) 
* add ActionState to the standard library

* use 1 ActionState, 1 get, 1 put in low-level trigger library

* introduce TriggerStateA for updateState

* fix tests and examples for new updateState signature

CHANGELOG_BEGIN
- [Triggers] The ``updateState`` function now returns a ``TriggerStateA``.  This
  is an action like ``TriggerA``, but doesn't permit emitting commands.  Instead
  of taking the state as an argument and returning a new state, you can
  manipulate the state with ``get``, ``put``, and ``modify``.  Any existing
  ``updateState`` can be ported by replacing ``s -> expr`` in the lambda
  expression with ``-> modify $ \s ->``, and then made to look nicer from there
  as desired.
  See `issue #7621 <https://github.com/digital-asset/daml/pull/7621>`__.
CHANGELOG_END

* some DAML docs for updateState and TriggerStateA
2020-10-09 13:56:24 -04:00
..
assistant Add a --timeout option to daml ledger commands (#6774) 2020-07-17 16:35:55 +02:00
bazel_tools add Action to high-level trigger updateState (#7621) 2020-10-09 13:56:24 -04:00
head_sdk Include the first feature in compat tests for create-daml-app (#6002) 2020-05-18 14:37:16 +02:00
sandbox-migration use -Ywarn-unused for all Scala code (#6907) 2020-08-07 13:16:09 -04:00
versions update versions bbased on git tags (#6580) 2020-07-02 16:37:13 +00:00
.bazelignore Extend compatibility tests to test against HEAD (#5714) 2020-04-24 14:43:35 +02:00
bazel-haskell-deps.bzl stack_snapshot_json on Windows (#7468) 2020-09-24 12:03:15 +00:00
BUILD replace commands-in-flight argument to trigger rule with getCommandsInFlight action (#7600) 2020-10-08 12:03:56 -04:00
build-release-artifacts-windows.ps1 reenable Windows cache (#7426) 2020-09-16 23:54:35 +02:00
build-release-artifacts.sh Remove redundant clean --expunge (#6890) 2020-07-28 09:49:36 +02:00
build-ts-libs.sh Include create-daml-app tests in compatibility tests (#5945) 2020-05-13 10:39:51 +02:00
deps.bzl Upgrade rules_scala (#6883) 2020-07-28 08:53:12 +00:00
maven_install.json update compat versions for 1.6.0-snapshot.20200915.5208.0.09014dc6 (#7417) 2020-09-17 08:19:46 +02:00
README.md Include sadbonx-classic in compatibility tests (#6399) 2020-06-19 15:55:39 +02:00
stack-snapshot.yaml Initial boilerplate for cross-version compatibility testing (#5665) 2020-04-23 12:58:11 +02:00
stackage_snapshot_windows.json stack_snapshot_json on Windows (#7468) 2020-09-24 12:03:15 +00:00
stackage_snapshot.json Add platform-version field to daml.yaml (#6736) 2020-07-15 16:30:01 +02:00
test-windows.ps1 reenable Windows cache (#7426) 2020-09-16 23:54:35 +02:00
test.sh Add platform-version field to daml.yaml (#6736) 2020-07-15 16:30:01 +02:00
update-versions.sh update versions bbased on git tags (#6580) 2020-07-02 16:37:13 +00:00
versions.bzl update compat versions for 1.6.0-snapshot.20201007.5314.0.b4a47d0b (#7605) 2020-10-09 13:40:16 +02:00
WORKSPACE Update rules_haskell (#7077) 2020-08-11 10:14:56 +00:00
workspace_status.sh Initial boilerplate for cross-version compatibility testing (#5665) 2020-04-23 12:58:11 +02:00

README.md

This directory contains the infrastructure and test setup for cross-version compatibility testing. We make this a separate Bazel workspace to make it easier to enforce that we only depend on release artifacts.

How to

Before using this, make sure to always run the scripts that build the SDK, namely ./build-release-artifacts.sh and ./build-ts-libs.sh. These should be run every time there is a relevant change you want to be there for this workspace to use.

Any Bazel command can then be used afterwards. ./test.sh are the tests run on CI.

What is currently being tested?

We include the following SDK versions in our tests:

  1. All stable SDK versions.
  2. All snapshots x.y.z-snapshot-* for which there is no stable release x.y.z
  3. HEAD.

Since running all tests can be rather slow, we run them in a daily cron job. On each PR we only include HEAD and the latest stable release.

Cross-version compatibility between ledger-api-test-tool

We test that the ledger-api-test-tool of a given version passes against Sandbox next and classic of another version. We test all possible version combinations here to ensure forwards and backwards compatibility. The ledger-api-test-tool includes a DAR built using a compiler from the same SDK version so this also ensures that sandbox can load a DAR from a different SDK version. We test both in-memory backends and postgresql backends.

Since all our JVM ledger clients use the same client libraries we consider the ledger-api-test-tool to be a good proxy and if things are not covered it should be extended.

Data-continuity for Sandbox classic

We have migration tests that work as follows:

  1. Start the oldest Sandbox version and upload a DAR.

  2. Iterate over SDK versions in order. For each version:

    1. Start sandbox of that SDK version.

    2. Run a custom Scala binary that interacts with the ledger to create contracts, exercise choices and query the ACS and the transaction service.

    3. Validates the results. This includes verifying that the transaction streams are the same after the migration and that the ACS is the same + additional test-specific checks.

We have two tests here: One that includes snapshot versions and one that only iterates through stable versions up to HEAD. This ensures that both individual migrations are correct as well as the migrations from one stable version to the next work as a whole.

Backwards-compatibility for DAML Script

We test that the DAML Script runner from a given SDK version can load DARs built against the DAML Script library from an older SDK. We only guarantee backwards compatibility here.

Backwards-compatibility for DAML Triggers

We test that the DAML Trigger runner from a given SDK version can load DARs built against the DAML Script library from an older SDK. We only guarantee backwards compatibility here.

Backwards-compatibility for data-dependencies

We test that we can import DARs built in older SDK versions via data-dependencies. We only test backwards compatibility here.

Cross-version compatibility for create-daml-app

We test that we can run the create-daml-app tests with JS client libraries and codegen from one version against the JSON API and Sandbox from another version. We test all version combinations here. Currently we do not test different versions of the JSON API and Sandbox. This should be covered by the ledger-api-test-tool tests since the JSON API uses the same client libraries.