Skip to content

Propagate task definition tags through RegisterTaskDefinition#43

Merged
teaguru merged 1 commit into
masterfrom
feat/propagate-task-def-tags
May 12, 2026
Merged

Propagate task definition tags through RegisterTaskDefinition#43
teaguru merged 1 commit into
masterfrom
feat/propagate-task-def-tags

Conversation

@teaguru
Copy link
Copy Markdown
Contributor

@teaguru teaguru commented May 12, 2026

Summary

  • DescribeTaskDefinition now requests TAGS via Include
  • RegisterTaskDefinition passes those tags through when registering the new revision
  • Applied consistently in lib/run.go, lib/deploy.go, and lib/runFargate.go

This keeps the tags on existing task definitions (typically set by Terraform) intact across ecs-tool deploys and run-task invocations.

Motivation

Without this change, every ecs-tool deploy / run creates a new task definition revision without tags, even when the previous revision (Terraform-managed) was correctly tagged. The tags effectively disappear on the next CI deploy and the service ends up pointing to an untagged revision.

This also unblocks deploys against AWS accounts where an SCP enforces mandatory tag keys on `ecs:RegisterTaskDefinition`. Example failure (from a WCC org SCP gating on `aws:TagKeys`):

```
AccessDeniedException: User: arn:aws:iam::...:user/...-deploy is not authorized
to perform: ecs:RegisterTaskDefinition on resource: ...task-definition/...:*
with an explicit deny in a service control policy: ...
```

With this PR, the new revision inherits the tags from the previous one, so `aws:TagKeys` is populated in the API request and the SCP passes.

Backward compatibility

Projects that don't tag their task definitions: `DescribeTaskDefinition` returns an empty `Tags` slice, and the `RegisterTaskDefinition` call passes nil tags as before. Behaviour unchanged.

Test plan

  • `go build` succeeds
  • `go test ./...` — existing tests pass (1 test: `TestParseTaskUUID`)
  • Manual end-to-end against a real AWS account:
    • Built local binary from this branch
    • Ran `ecs-tool run` against a preview ECS cluster whose task definition revision had the required tags
    • New revision was registered successfully and inherited all tags from the previous revision (verified via `aws ecs describe-task-definition --include TAGS`)
    • Prior to this patch, the same call returned `AccessDeniedException` on `ecs:RegisterTaskDefinition` due to the SCP

DescribeTaskDefinition now requests TAGS, and RegisterTaskDefinition
passes them through when registering the new revision. This keeps the
tags on existing task definitions (typically set by Terraform) intact
across ecs-tool deploys and run-task invocations.

This unblocks deploys against AWS accounts where an SCP enforces
mandatory tag keys on ecs:RegisterTaskDefinition: the new revision
inherits the tags from the previous one, so aws:TagKeys is populated
in the API request.

Behaviour for projects that don't tag their task definitions is
unchanged - DescribeTaskDefinition returns an empty Tags slice, and
the RegisterTaskDefinition call passes nil tags as before.
@teaguru teaguru merged commit 5a34447 into master May 12, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant