* 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.
@dylant-da is taking care of [testing](https://github.com/digital-asset/daml/blob/main/release/RELEASE.md) today's release, so they get pushed back to the end of the line.
Please do not merge this before the release is fully tested.
Co-authored-by: Azure Pipelines Daml Build <support@digitalasset.com>
* Add flag
* Add flag for bazel macro daml_compile
* Add flag for bazel macro daml_test
* LF Conversion: fail if interfaces or interface instances are defined without --enable-interfaces=yes
* Add --enable-interfaces=yes where needed
