chore: Add validation to test release codebuild spec #326
Conversation
Now the test release validation does the same checks as the prod release (running the sample application against the new version). To support this I've also refactored out the validation steps into a dedicated spec so both the prod and test specs can depend on it.
farleyb-amazon
force-pushed
the
release-validation
branch
2 times, most recently
from
6a72e0a to
a0c74cf
Compare
farleyb-amazon
force-pushed
the
release-validation
branch
from
a0c74cf to
5021ea4
Compare
| - git checkout $COMMIT_ID | ||
| - FOUND_VERSION=$(sed -n 's/__version__ = "\(.*\)"/\1/p' src/aws_encryption_sdk/identifiers.py) | ||
| - | | ||
| if expr ${FOUND_VERSION} != ${VERSION}; then |
There was a problem hiding this comment.
I'm assuming VERSION has to be provided manually when executing this build? Is there a good place to document a repository's available build commands and how to call them?
There was a problem hiding this comment.
Correct, and good question. There is a spot for environment variables, but it looks like they do require you pass a value, and I didn't want to provide a default for the version. Worst case we could add comments, but let me look a bit more to see if there are other options.
codebuild/release/test-release.yml
Outdated
| fast-fail: false | ||
| build-list: | ||
| fast-fail: true | ||
| build-graph: | ||
| - identifier: test_release |
There was a problem hiding this comment.
These labels are a little confusing: in isolation I'm not sure if this one means "test the release" or "release the test artifact". Perhaps we can use phrases like "release to production" vs "release to staging"?
There was a problem hiding this comment.
Makes sense, will update wording.
| runtime-versions: | ||
| python: latest | ||
| pre_build: |
There was a problem hiding this comment.
What's the functional difference between build and pre_build?
There was a problem hiding this comment.
To be honest I haven't found a clear description of any functional differences. The docs provide some examples of what you could do in each one, but there doesn't seem to be anything concrete. My grouping here is fairly arbitrary, so I'm open to suggestions.
There was a problem hiding this comment.
This is fine, it looks like pre_build/build/post_build are really just to help organize the phases, and this seems to fit well.
Now the test release validation does the same checks as the prod release (running the sample application against the new version). To support this I've also refactored out the validation steps into a dedicated spec so both the prod and test specs can depend on it.
Now the test release validation does the same checks as the prod release (running the sample application against the new version). To support this I've also refactored out the validation steps into a dedicated spec so both the prod and test specs can depend on it.
Description of changes:
Now the test release validation does the same checks as the prod release (running the sample application against the new version), but targeting testpypi. To support this I've also refactored out the validation steps into a dedicated spec so both the prod and test specs can depend on it.
Testing:
Prod and test releases succeed (without any version uploaded, because it hasn't changed) when I give them the correct version and commit.
When I give a bad commit, we fail to checkout the branch and stop.
When I give a good commit but bad version, we detect that the authoritative version in
identifiers.pydoes not match the requested version and stop.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.