-
Notifications
You must be signed in to change notification settings - Fork 301
Add integration tests that follow our EC2 tutorial #769
Conversation
|
Output from CodeBuild: |
|
|
||
| // Then | ||
| stdout.Stdout(out).TestHasAllSubstrings(t, []string{ | ||
| "Started container", |
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 wish there was an easy way to guarantee that the right number of tasks are running.
I think this is fine for now though.
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 see this is done using ps in the actual integ test 👍🏻
| // Increase the number of running tasks | ||
| cmd.TestTaskScale(t, project, 2) | ||
| ecs.TestListTasks(t, conf.ClusterName, 2) | ||
| cmd.TestPsRunning(t, project, 4) |
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.
The numbers here confuse me... after TestTaskUp, why are 2 containers expected in PS?
And after scaling to 2 tasks, why are 4 containers expected in PS?
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.
Yeah, I can totally understand the confusion.
If you look at the compose file, we have two containers listed out. So that 1 task with two containers. When we scale the number of tasks to 2, then we end up with 4 running containers in the cluster.
I'll add comments explaining this in the integ test.
|
|
||
| // TestListTasks validates that a cluster has the expected number of | ||
| // tasks by periodically querying against ECS. | ||
| func TestListTasks(t *testing.T, clusterName string, wantedSize int) { |
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.
😎
| ./scripts/build_binary.sh ./bin/local | ||
| @echo "Running integration tests..." | ||
| go test -tags integ -v ./ecs-cli/integ/e2e/... | ||
| go test -timeout 60m -tags integ -v ./ecs-cli/integ/e2e/... |
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.
just curious: do we know how long these tests are taking to run on average? wondering if we can track length of test runs in CloudWatch so we can keep an eye on things as we add more tests.
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.
After making the tests run in parallel, it came down to ~11 mins from ~17mins.
The default go test timeout is 10m, that's why i had to override that value. I picked 60m to be consistent with the codebuild timeout.
ecs-cli/integ/e2e/ec2_task_test.go
Outdated
|
|
||
| func createEC2TutorialComposeFile(t *testing.T) string { | ||
| content := ` | ||
| version: '3' |
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.
what do you think about using version: 2 compose for this test? We support both but parsing takes diff code paths, so using v2 here and keeping v3 in the Fargate test would increase total line coverage.
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.
Great suggestion, updated!
Description of changes: Add integration tests that follow our EC2 tutorial (https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-cli-tutorial-ec2.html)
Testing
Documentation
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.