Skip to content

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

Merged
merged 7 commits into from
Sep 19, 2023

Conversation

lavaleri
Copy link
Contributor

@lavaleri lavaleri commented Sep 15, 2023

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

@lavaleri lavaleri marked this pull request as ready for review September 19, 2023 18:43
@lavaleri lavaleri requested a review from a team as a code owner September 19, 2023 18:43
Copy link
Contributor

@ajewellamz ajewellamz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@josecorella josecorella left a 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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@lavaleri lavaleri merged commit 497c332 into main Sep 19, 2023
@lavaleri lavaleri deleted the mpl-script branch September 19, 2023 19:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants