Add Ability to fetch the Task Definition Using AWS API for Node and Then Rendering it.

[mangeshg]

Currently this workflow expects to have the Task Definition Json to be part of the GitHub Repo.

If this action can be enhanced to fetch the task definition just by using family:revision provided to AWS.ECS. describeTaskDefinition API and then rendering it further , Then Users do not need to check in the task definition Json in the Repo.
Optionally - Updated task definition can be registered back using registerTaskDefinition API call with updated ECR Image ID.

This will achieve -

1. Better user confidence to avoid checking in Spec file containing references to various AWS ARNs (Account Id ) etc.
2. It will be guaranteed that Task Definition will always be correct / no need to validate its format specs etc.

[paragbhingre]

@mangeshg Thank you for reporting this feature request to us, we will look into this and get back with the appropriate answer to it.

[mangeshg]

@paragbhingre Thanks Parag , Looking forward to it.

[pktippa]

I am also waiting for this feature to be available, I am also willing to contribute if someone can guide me through.

[sblack4]

This would be nice. My workaround is to run this step before the render task def step:

    - name: Get current task definition
      run: >
        aws ecs describe-task-definition
        --task-definition "$TASK_FAMILY" --region "$AWS_DEFAULT_REGION" --query 'taskDefinition'
        > task-definition.json

[protonforest]

Looking forward to this feature!

[scott-doyland-burrows]

describe-task-definition

Good workaround, but the issue with this is that the tags are not pulled into the task definition. And removing the --query 'taskDefinition' and including --include TAGS then means it just fails, as the task def is not in the correct format.

[anitakrueger]

describe-task-definition

Good workaround, but the issue with this is that the tags are not pulled into the task definition. And removing the --query 'taskDefinition' and including --include TAGS then means it just fails, as the task def is not in the correct format.

We do the following to get the task definition including tags and then sanitize the definition:

        aws ecs describe-task-definition \
          --task-definition ${{ inputs.task_definition }} \
          --include TAGS > task-definition.json

        jq '
          .taskDefinition.tags += [.tags[]] |
          del(.tags) |
          .taskDefinition |
          del(.compatibilities,
              .registeredAt,
              .registeredBy,
              .revision,
              .requiresAttributes,
              .status,
              .taskDefinitionArn)' task-definition.json > clean-task-definition.json

I am surprised that after 3 years of this being open, AWS hasn't taken any action.

[shesaave]

Hi @anitakrueger,
Thank you for your patience, I am happy to share that we are currently working on this feature. Stay tuned! I appreciate your motivation to continuously be on the lookout for improving ECS GitHub Actions :-)

[FISHMANPET]

I just tried out using this latest version of the task that will fetch the task definition, however it didn't fetch any of the tags, so when I registered that task definition with the amazon-ecs-deploy-task-definition action, it was created without any tags.

It also rends a bunch of extra data that isn't needed (specifically the 7 properties that @anitakrueger removes in the jq command above). The deploy task prints a warning that they're present and will be ignored, but can be removed.

If these two tasks are expected to be used together, I would expect rough spots like this to be fixed up.

[karanbokil]

Hi @FISHMANPET, thanks for suggesting these improvements - if it wouldn't be too much of a bother, could you please open new issues to:

1. Fetch tags with the task definition
2. Remove the extra data from the fetched task definition
   Want to ensure you are credited as the issue opener, but will credit you as the source if you would like me to open instead.
   The reason I ask is because I am closing this issue since the feature by and large has been delivered, but any further improvements will be better tracked in their own issues.

[FISHMANPET]

No worries, I just opened #317