-
Notifications
You must be signed in to change notification settings - Fork 15
chore: Always test/build with locally built MPL and add release safeg… #422
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
left a small nit but LGTM
@@ -0,0 +1,4 @@ | |||
projectJavaVersion=3.1.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: should this be dbesdkJavaVersion instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, I was thinking that it would be more obvious that this meant "this project". I.e. if the MPL implemented a similar thing, it would use projectJavaVersion
to mean what Java version of the MPL we're on.
…uards
Updates CI to build/test using local MPL, making it easier to reason about local development, and unblock development with pre-release MPL features.
We already ensure in our release process that we test the examples and test vectors against MPL in maven local, but this PR adds an additional script to ensure there is consistency between the MPL submodule and the MPL version in our build.gradle that can be used before and during a release. It isn't checked in CI, in order to support development against pre-release MPL.
Updated the build.gradle to use the same versions of MPL/Dafnyruntime/etc. across the DB-ESDK, examples, and test vectors. These versions are currently defined in a top level
properties
file, that each individual gradle project reads from. This is Java specific for now, to give us the best bang for our buck today.Once effect of this is that I think these dependencies will no longer be caught by dependabot. This is probably ok, as we want to be mindful when upgrading these dependencies anyway.
Tested the Codebuild script update on commits 94fc4b4, 79926a4, and e219262 to ensure expected success/failures.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.