Running a task is the most complex behavior of any of the stubbed
endpoints and consequently, is the one I least exhaustively stubbed.
There's a lot of validation happening internally in the service that
isn't captured in botocore's parameter validation; luckly a lot of it is
documented in the API reference:
I've faked the behaviors that I anticipate being most relevant to our
EcsRunLauncher. Particularly, Our reference ECS deployments run with
launchType = "FARGATE" and networkMode = "awsvpc". Tasks using that
networkMode must include an awsvpcConfiguration but that validation
takes place in the ECS service and not in botocore. So our stub fakes
As we expand the ECS configurations that we support, we'll need to
expand the flexibility of this stub as well. This is the behavior that
will benefit most from an end-to-end integration test against a live
endpoint once development is more complete.
Also, rather than stub all the cluster endpoints, this just assumes
you're passing a valid cluster. That's a simplification I felt
comfortable taking becuase - unlike task definitions - the cluster
doesn't really have meaningful behavioral implications for our use of
the run endpoint.