* Resolve release version for sdk build checks
* lint
* lint
run-full-compat: true
* Simple test for using daml-script in release versions
* Fix build issues in tests using pSdkVersion
run-full-compat: true
* Fix build issues with DamlcIntegration
* fix bad sdk version being an invalid version
run-full-compat: true
* Fix the linux "mmap 4096 bytes at (nil): Cannot allocate memory" error
* Fix compat tests on Windows
run-full-compat: true
* test windows os correctly
run-full-compat: true
* temporarily disable canton_3x
run-full-compat: true
---------
Co-authored-by: Paul Brauner <paul.brauner@digitalasset.com>
* build canton 3.x in build.yml
* Apply suggestions from code review
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
* Apply suggestions from code review
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
* apply suggestions
---------
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
* do not run pr-only tests on main, do not run main-only tests on prs
* split data dep tests into main-only and pr-only
* run non-dev conformance tests on main only
* introduce a canton2 directory
* rename to canton-3x and only keep the bazel rules
* add canton-3x to bazelignore
* fix visibility rules
* add a build-canton-3x script
* add build-canton-3x.sh temporarily to prs.yml to test it out
* try sending a message to stack when failing
* backport 243125adee
* restore prs.yml and add the job to azure-cron.yml
* restore tell-slack-failed condition
* address comments
* display the revision at which canton was cloned, to ease debugging
* pin dependencies to json and add missing dep
* fix cyclic dep
* remove unused dep
* add missing dep to //ledger-api/testing-utils:testing-utils
* remove unused dep in //ledger/ledger-api-auth:ledger-api-auth
* remove more unused deps
* more dep fixes
* yet more dep fixing
* more fixing..
* more of the same
* hopefully the last deps to fix
* Bump the version of protobuf and fix everything that depends on it. Took shortcuts that I need to fix in a next commit, but would like to run the CI on this now that it compiles
* don't error out in the grpc-haskell patch
* remove obsolete patch
* patch absl to compile on mingw
* Add a patch to recognize the compiler
* Define _DNS_SD_LIBDISPATCH for macOS gRPC
* bump netty_tcnative_version according to https://github.com/grpc/grpc-java/blob/master/SECURITY.md#netty
* pin maven deps
* Fix macos linking errors 'dyld[xxx]: missing symbol called'
* Skip Darwin frameworks in package-app.sh
* pin stackage packages
* pin stackage windows deps
* use the netty version agreed on
* bump the windows global cache to try and debug the upb issue
* restart the CI after timeout
* clean up
* disable failing tests for now
* comment out unused code
* reset the windows machine name to 'default'
---------
Co-authored-by: Moisés Ackerman <6054733+akrmn@users.noreply.github.com>
Turns out some people depend on it. I still think they shouldn't, and we
should work with them to help them move away, but short-term the right
thing to do is to not block their upgrade.
* Fix the external name of daml3-script.dar to mention 2.dev
* make the compilation and distribution of daml3-script dars more future proof
* fix path in ci/copy-unix-release-artifacts.sh
The latest udpate of the BlackDuck script broke our run. In order to get
a successful scan tomorrow, this PR:
- Pins us back on yesterday's script version, and
- Adds an auto-update mechanism.
This way, we get to stay reasonably up-to-date with automated update
PRs, but we also get to choose when we upgrade.
* Update to rules_haskell v0.16
* Update comments re bazel patches
* clean up bazel overrides
* Upgrade to Bazel 5.2.0
* Remove '--distinct_host_configuration=false'
* Update buildifier to 6.3.2
* Suffix macos and ubuntu caches with yyyymm
* bump windows cache to v14
* [REVERTME] bump linux/macos/darwin timeout to 4h
If the ledger has been pruned more recently that the last cached copy, then attempting to fetch the changes since that last offset will fail, rending the relevant template(s) unqueryable. This PR detects that condition, clears the cache for the relevant template and queries again, which will refresh the cache with a fresh copy of the ACS for that template, and serve the query from that.
I also made some usability tweaks around running canton-ee tests, to help improve the dev experience for failures I came across while trying to run them. Specifically
* Use `--config=canton-ee` to opt into the tests which require canton-ee
* When downloading that EE from artifactory, provide better diagnostics if the required auth isn't set up.
For the used-to-be-rare-but-not-so-much-anymore case where the job fails
after having pushed its logs (without this the push fails as we can't
overwrite artifacts).
This was spurred by the fact that the "report_end" task sometimes fails
on m1 with the "install Bash lib" step just never finishing (and the
whole job then times out after 6h).
Hopefully by running fewer things we get fewer chances of these kinds of
weird issues.
Note that it's unclear if anything actually crashes on the m1 machines
or if this is a loss of connection between Azure Pipelines and the
machine. From what I've seen as soon as that job times out the machine
is able to successfully pick up other jobs. Speaking of, I've also
reduced the 6h timeouts to a more reasonable 3h.
We routinely have upwards of 3GB of logs. They are very rarely
downloaded, most people don't even know they're there. Uploading 3GB
takes time. This should make it faster, hopefully.
* remove sandbox-on-x project
update bazel readme
update release artifacts
comment out last remaining SoX test
remove ledger-runner-common
remove participant-state-kv-errors
remove recovering-indexer-integration-tests
remove participant-integration-api
update doc pages
cleanup ledger-api-auth usage
remove participant-state
fix build
fix build
clean up ledger-api-common part I
clean up ledger-api-comon part II
clean up ledger-api-common part III
remove ledger/metrics
clean up ledger-api-health and ledger-api-domain
* remove ledger-configuration ad ledger-offset
* remove ledger-grpc and clean up participant-local-store
* reshuffle few more classes
* format
* fix blackduck
BlackDuck is currently failing to run because it creates multiple report
files and then expects a single one. This is due to #16552 changing only
one of the output file names.
This PR resolves this by:
1. Changing the name everywhere, so all runs aggregate their results on
the same file.
2. Changing the PR step code to expect the given file name, rather than
try and glob it.
My understanding of the BlackDuck setup is very fuzzy so please
double-check carefully.
See #16600 for an example of what the update would be from this PR.
* Update daily-compat.yml
main instead of local-main-maven
---------
Co-authored-by: Brian Healey <brian.healey@digitalasset.com>
I _believe_ this is what has been tripping up the check-releses job for
the past few days: while updating the signing key, I did not update the
key fingerprint to match, and therefore trying to check any signature
fails.
The failure mode of the existing script is still pretty bad, regadless:
looping on the same release until the hard drive is full is definitely
not expected. Our retry policies are supposed to have time bounds, and
failure should result in cleaning up the workdir.
run-full-compat: true
