* 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.
