* 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>
* 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>
* Add buildifier targets.
The tool allows to check and format BUILD files in the repo.
To check if files are well formatted, run:
bazel run //:buildifier
To fix badly-formatted files run:
bazel run //:buildifier-fix
* Cleanup dade-copyright-headers formatting.
* Fix dade-copyright-headers on files with just the copyright.
* Run buildifier automatically on CI via 'fmt.sh'.
* Reformat all BUILD files with buildifier.
Excludes autogenerated Bazel files.
