[ECS/Fargate] [request]: Support environment variables with blank values in S3 environment files

[nbrowz]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request This request is similar to https://github.com/aws/amazon-ecs-cli/pull/167 for ECS/EC2, but for ECS/Fargate instead.

Currently for ECS/Fargate, if a container definition references an environment variable file stored in S3 that contains variables with blank values, those variables will not show up in the container. For example: let's say I create a file with variable SOMETHING=, and store it in S3. Next, I set my container definition to use this file inside my task definition, and create a task from the task definition. I'd expectprintenv in the resulting task's container to display the variable SOMETHING=, but instead the variable isn't displayed at all.

I would like for containers to have these variables set regardless of their values.

Which service(s) is this request for? ECS/Fargate

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? We're using a Docker image that runs an application expecting certain environment variables exist, even if they have a blank value. If environment variables with blank values are not set on the container, the application will fail to start.

Are you currently working around this issue? By directly setting environment variables with blank values in the container definition instead of referencing an environment variable file that contains variables with blank values.

Additional context None

Attachments None

[dejanceltra]

Additionally, docker and docker-compose follow the behaviour of supporting variables with blank values (even in .env files), so this is another reason that env files shouldn't deviate from that.