* Disable keys in LfConversion.
* fix UnusedMatchTests.daml in integration-v21
* fix //compiler/damlc/tests:upgrades
* stop compiling daml tests that use keys with 2.1
* migrate the upgrade examples to 2.dev as they use keys
* only compile daml-script/tests dar using keys to 2.dev
* do not compile daml-script/test daml files that use keys to 2.1
* fix //docs:bindings-java-daml-test
* add TODOs everywhere tests need to be split
* add a tests that checks that contract keys are rejected for LF<2.dev
* remove keys from compatibility tests
* Add the qualified template name to the keys not supported error message
* update canton to 20240402.13019.v58aad7d4
tell-slack: canton
* align tink with canton's
---------
Co-authored-by: Azure Pipelines Daml Build <support@digitalasset.com>
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
* update canton to 20240327.13000.vb4399545
tell-slack: canton
* remove dependencies as requested by Bazel
---------
Co-authored-by: Azure Pipelines Daml Build <support@digitalasset.com>
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
When we manually run the daily-snapshot job to make a specific commit,
the resulting release should be named based on the release commit, not
the trigger commit.
* update canton to 20240326.12988.v061093f7
tell-slack: canton
* set PV=dev when config.devMode is true in the Canton fixture
* honor devVersionSupport in Sandbox.hs
* fix //language-support/ts/codegen/tests:build-and-lint-test
* explicitly set dev-version-support in the sequencer and mediator in Sandbox.hs
---------
Co-authored-by: Azure Pipelines Daml Build <support@digitalasset.com>
Co-authored-by: Paul Brauner <paul.brauner@digitalasset.com>
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.
* add -fobject-code to fix da-ghci[d]
* stage everything for Sam :-)
* Staging up last changes for Sam - track pending requests & SMethod types
* Some cleanup, get vscode working again with full parsing
* Cleanup
* Add TODO notes
* First multiple SubIDE support
* Cleanup and polish initial multi-ide
* First version of cross IDE goto definition
* Small cleanup
* Update TODO
* Linting
* Fix shutdown logic for windows
* Update ghcide, fix merge warning
* Read multi-package.yaml
* First review comments addressed
* Second batch of fixes
* Penultimate batch of changes
* Add errors as shown messages
* Add client progress token prefixing
* Review/ci fixes
* Update ghcide to main
* Update comment
---------
Co-authored-by: Dylan Thinnes <dylan.thinnes@digitalasset.com>
This is an attempt to test whether the configuration in #18812 is
sufficient to successfully create a release, as I try to find out the
minimal set of things we need to explicitly build.
Note that by its very nature the ad-hoc release we're creating here will
reference a transient, ephemeral commit.
* update canton to 20240325.12966.v2a7db959
tell-slack: canton
* Remove enable-contract-upgrading flag from Canton runner
---------
Co-authored-by: Azure Pipelines Daml Build <support@digitalasset.com>
Co-authored-by: Tudor Voicu <tudor.voicu@digitalasset.com>
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.
