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
* Add support for env vars in some config files
* Fix interpolation as per design doc
* Allow env var errors to pass through multibuild
Refactor env var logic to provide hasReplaced flag
* Update daml-project-config cabal
* Added daml assistant warning
* Added scala ProjectConfig env var support + tests
* Added haskell ProjectConfig tests
* Formatting
* Refactor haskell interpolation. Remove dot replacement
* Refactor assistant warning logic
* Remove unused annotation from scala test
* Add field for disabling interpolation
* Revert stackage_snapshot change
* Remove unnecessary pragma
* Add interpolation field to scala side
* Add tests for disabling interpolation