Skip to content
This repository was archived by the owner on Nov 19, 2025. It is now read-only.

Conversation

@allisaurus
Copy link
Contributor

Add support for RepositoryCredentials.CredentialsParameter to ecs-params.yml

Test output:

docker-compose.yml:

version: '3'
services:
  wordpress:
    image: httpd
    ports:
      - "80:80"

ecs-params.yml:

version: 1
task_definition:
  task_execution_role: ecsTaskExecutionRole
  services:
    wordpress:
      repository_credentials:
        credentials_parameter: arn:aws:secretsmanager:XXXXXXXXXX:secret:XXXXXXXX
      cpu_shares: 27
      mem_limit: 524288003

CMD output:

$~\credParamTest> ..\..\Documents\GO\src\github.com\aws\amazon-ecs-cli\bin\local\ecs-cli.exe compose create
INFO[0000] Using ECS task definition                     TaskDefinition="credParamTest:5"

Created task def:

{
    "executionRoleArn": "arn:aws:iam::XXXXXXXXX:role/ecsTaskExecutionRole",
    "containerDefinitions": [
        {
            "portMappings": [
                {
                    "hostPort": 80,
                    "protocol": "tcp",
                    "containerPort": 80
                }
            ],
            "cpu": 27,
            "repositoryCredentials": {
                "credentialsParameter": "arn:aws:secretsmanager:XXXXXXXXXX:secret:XXXXXXXX"
            },
            "memory": 500,
            "image": "httpd",
            "essential": true,
            "name": "wordpress"
        }
    ],
    "family": "credParamTest",
}

--
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@allisaurus allisaurus changed the title Dev Add support for credentials_parameter Aug 2, 2018
credParam := ecsContainerDef.RepositoryCredentials.CredentialsParameter

if credParam != "" {
outputContDef.RepositoryCredentials = &ecs.RepositoryCredentials{}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This it totally fine, but just wondering aloud: We are sometimes inconsistent with using the setters on objects vs just assigning the field to an empty version of it. E.g. we're using SetCredentialsParameter in line 185, but not SetRepositoryCredentials in line 184. Is this something we might want to think about?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, we are inconsistent with this. But they're each more concise depending on what you want to do.

In the case of setting up a RepositoryCredentials, if I wanted to use the setter method I'd have to create an empty struct first, and then set it with the method (otherwise it'd set it to an empty pointer, so I wouldn't have a thing to call SetCredentialsParameter on), so setting directly like on line 184 just lets me do it in one line. On 185 the value I want to set already exists, so I use the setter method, which also takes care of converting it to a pointer so I don't have to do aws.String().

This isn't definitive guidance of course, but perhaps using either depending on what results in fewer lines of code might be one way of deciding?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants