With the current setup, every single day we download every single
artifact of evry single release we've ever made on GitHub, twice (once
from GitHub, once from GCS). Then we check signatures and compare the
two.
With this change, we save a representation of the state of both GCS and
GitHub, and if that representation hasn't changed, we assume the
artifacts haven't changed either. The assumption seems reasonable to me
as the representation includes platform timestamps, which no user can
tamper with as far as I'm aware.
Note: we do not save the entire GitHub release representation, and
instead just save relevant metadata for the associated artifacts. The
goal of this job is to verify that the artifacts haven't changed; it is
acceptable (and even expected in routine circumstances) that the
release description will change, as well as its "prerelease" and "latest
release" flags.
Specifically:
- m1 builds
- BlackDuck & notices bump
- daily compatibility tests
- daily compat update (if needed)
- daily perf test & report
Also, merge the canton update jobs as that makes a lot more sense at
this point. Future divergences can be expressed by changing the files in
their respective branches.
This PR will need to be backported to main-2.x to fully take effect.
* 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.
