chore: Add initial codebuild specs for automating release #243
Conversation
For now, these specs only deal with validation. However, I'm using the structure that includes a place for the release itself (currently a no-op) so that we can easily add that once we're ready.
| variables: | ||
| JAVA_ENV_VERSION: openjdk8 | ||
| JAVA_NUMERIC_VERSION: 8 | ||
| image: aws/codebuild/standard:3.0 |
There was a problem hiding this comment.
3.0 is deprecated now: https://docs.aws.amazon.com/codebuild/latest/userguide/build-env-ref-available.html Does 4.0 work?
There was a problem hiding this comment.
Interestingly, it does not, because 3.0 is the only one that supports openjdk: https://docs.aws.amazon.com/codebuild/latest/userguide/available-runtimes.html
Given that 3.0 is deprecated, we'll need to think about what our long term support plan is for openjdk.
| SONA_USERNAME: Sonatype-Team-Account:Username | ||
| SONA_PASS: Sonatype-Team-Account:Password |
There was a problem hiding this comment.
These aren't actually used since the release steps themselves are no-ops, correct? I'm fine with leaving these here for now but worth a comment.
There was a problem hiding this comment.
Correct, I've left them in with the expectation that we'll shortly be making use of them.
There was a problem hiding this comment.
Oh, and I haven't found a good way to add comments in codebuild specs :(
There was a problem hiding this comment.
Darn. I can live without them.
| -Dmaven.compiler.target=$JAVA_NUMERIC_VERSION \ | ||
| -Dmaven.compiler.source=$JAVA_NUMERIC_VERSION |
There was a problem hiding this comment.
Are these two properties necessary? Given you're running on either 8 or 11 based on the runtime version config, wouldn't it better represent the common customer experience to stick to the default?
There was a problem hiding this comment.
They actually are necessary, because the pom currently defaults these to 11. So if you're running in the Java 8 environment but this project is trying to compile to Java 11, it gets unhappy.
There was a problem hiding this comment.
Ah okay, it's another consequence of using a single consumer to test both version then.
For now, these specs only deal with validation. However, I'm using the structure that includes a place for the release itself (currently a no-op) so that we can easily add that once we're ready.
For now, these specs only deal with validation. However, I'm using the structure that includes a place for the release itself (currently a no-op) so that we can easily add that once we're ready.
Description of changes:
For now, these specs only deal with validation. However, I'm using the structure that includes a place for the release itself (currently a no-op) so that we can easily add that once we're ready.
Unlike in the Python ESDK, I made separate files for validation of prod vs staging releases, since the steps to hit the staging repository are a pretty big delta from hitting normal public repos.
Testing:
I've tested both the prod and release targets, including staging a version not on public maven to make extra sure that the staging validation is actually hitting the staging repository.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.