-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
[AWS SageMaker] Add CodeBuild Steps #3668
Merged
+125
−0
Merged
Changes from 1 commit
Commits
Show all changes
23 commits
Select commit
Hold shift + click to select a range
101c43a
Add initial unit test buildspec
0c6e612
Add docker log output
7a16c0c
Add force no pytest color
532f204
Update docker build to be quiet
c1698e3
Add pass all environment variables
b1a3c64
Update unit test container env file
0e740a9
Update env to use different syntax
beb0410
Remove daemon mode
aed8465
Remove TTY from docker run
7288143
Add dryrun and dockercfg setup
365600a
Update dryrun into CodeBuild logic
ac489da
Add mkdir for Docker config
d1f5598
Update app version temporarily
9aa9647
Revert app version temporarily
54b87f4
Update unit test log file
f09c2a4
Add tag minor and major versions
dc2a090
Update version temporarily
b65cf3d
Add print for major and minor tags
b50442b
Revert version back down
cadc6f8
Add deploy version override
4c89da5
Update path to testing directories
c45ed50
Fix tab formatting
517d215
Fix pytest log directory
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev
Previous commit
Fix pytest log directory
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Design question:
Especially with integration test and deploy - the test container needs IAM permissions, and maybe things where it need access to resources outside the codebuild job so we can use avoid passing them explicitly here.
Also we can maintain only one image per job rather than a base image + step specific image
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.
I worry that this would add additional complexity to the build process that may be prone to failure. We now need another CodeBuild project and ECR repo to build and then host the test images, and our integration test project would need to point to a specific tag in that repo. Developers would now need to know that they had to run the build step before the integration test step for every run - rather than simply running the one step. I don't think this would save time either, since the time to spin up the codebuild run, build the container, upload to ECR and then finally run the integration test codebuild project would surely be more time than building it and running it in one.
My ideal world would be this:
.env
file and then build and run the integration test Dockerfile. Everything would be created automatically (except data maybe) and all of the tools needed for testing would be included in that Docker container.The current implementation of CodeBuild uses the
standard:3.0
base image, which has Docker and Python in it if we need those. I have already included in this CodeBuild spec the ability for the outer CodeBuild container to pass all of its environment variables through to the inner (integration test) container. This allows us to simply pass any values in from our CDK infra to the CodeBuild container and the integration test container would be able to access them - this includes role permissions.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.
It is fairly common for projects to have a "codebuild" directory, but I've seen both solutions. I think because each of these codebuild steps does roughly the same thing (build and run a container), they should stay fairly close together so we remember to update them. They also don't really have anything to do with the actual unit or integration tests themselves - I wouldn't expect anyone else to care about them except us.