and then volume mounting the aws-sdk-go-v2/aws-models and aws-sdk-go-v2/service directories to the container. When the container runs, it reads the JSON models from aws-sdk-go-v2/aws-models and writes the generated client code and go.mod files to packages in aws-sdk-go-v2/service.
Notes
The aws-sdk-go-v2/aws-models directory currently contains our bespoke ecs.json model. If we need more custom clients in the future, we add their JSON models to this directory.
The aws-sdk-go-v2/service directory only contains an ecs package since we currently only generate an ECS client.
To generate clients, run make gogenerate-aws-sdk.
Differences between our ecs package and the SDK's:
Some input/output types have additional fields. These additions were ported over from our existing bespoke models.
The SDK's go.mod uses replace directives to reference other modules in the repo. Ours does not because, while our clients are customized, their dependencies should still be the official SDK modules.
Generated clients must be in their own go modules with paths like github.com/aws/aws-sdk-go-v2/service/${service} because they import packages internal to github.com/aws/aws-sdk-go-v2.
Our ecs-agent and agent go modules will eventually use our bespoke ECS client by depending on our local aws-sdk-go-v2/service/ecs module. They should continue depending on official aws-sdk-go-v2 modules for everything else, however. This can be accomplished with replace directives, e.g.
### Testing
This PR only includes codegen changes and the generated ECS client. The client is not used anywhere yet.
In a separate branch, I have replaced our `aws-sdk-go` ECS client with our bespoke `aws-sdk-go-v2` ECS client and tested that everything compiles.
New tests cover the changes: no
### Licensing
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Summary
Add support for generating our own bespoke ECS client that's compatible with
aws-sdk-go-v2
.Implementation details
aws-sdk-go-v2
uses the Smithy Gradle plugin to generate client code.At a high level, the SDK
smithy-build.json
files for every JSON model in theaws-models
directorysmithy-build.json
filesgo.mod
files for each service packageWe simulate this process by building a Docker image with
smithy-go
)smithy-go
Gradle pluginaws-sdk-go-v2
repoand then volume mounting the
aws-sdk-go-v2/aws-models
andaws-sdk-go-v2/service
directories to the container. When the container runs, it reads the JSON models fromaws-sdk-go-v2/aws-models
and writes the generated client code andgo.mod
files to packages inaws-sdk-go-v2/service
.Notes
aws-sdk-go-v2/aws-models
directory currently contains our bespokeecs.json
model. If we need more custom clients in the future, we add their JSON models to this directory.aws-sdk-go-v2/service
directory only contains anecs
package since we currently only generate an ECS client.make gogenerate-aws-sdk
.ecs
package and the SDK's:go.mod
usesreplace
directives to reference other modules in the repo. Ours does not because, while our clients are customized, their dependencies should still be the official SDK modules.github.com/aws/aws-sdk-go-v2/service/${service}
because they import packages internal togithub.com/aws/aws-sdk-go-v2
.ecs-agent
andagent
go modules will eventually use our bespoke ECS client by depending on our localaws-sdk-go-v2/service/ecs
module. They should continue depending on officialaws-sdk-go-v2
modules for everything else, however. This can be accomplished withreplace
directives, e.g.replace github.com/aws/aws-sdk-go-v2/service/ecs => ../aws-sdk-go-v2/service/ecs