feat: add environment-variables support

[Misterio77]

Issue #, if available: #112

Description of changes: These commits add a environment-variables input. It accepts KEY=value environment variables, separated by |.

For example: VARIABLE_NAME=value|ANOTHER_ONE=foo|YET_ANOTHER=bar.

Those are added to the rendered task definition: if the environment array does not exist, it is created. if the specified KEY name is present it is updated, if not, created as well.

I've updated the tests to include testing for all these cases (creating array, update existing, create new, not touching one that is already there, etc), all is missing currently is a test case for the new throw (when the input has an invalid format).

Here's an usage example, to update a container environment variable with the deployed tag (my use case requires that variable to return, at request, the currently running service vesion, which otherwise would not be accessible at run-time):

name: Deploy

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Version to deploy'
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: us-east-1

    - name: Fill in the new image ID in the Amazon ECS task definition
      id: task-def
      uses: Misterio77/amazon-ecs-render-task-definition@v1.1.0-pre3
      with:
        task-definition: ecs_task.json
        container-name: backend
        image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/backend:${{ github.event.inputs.version }}
        environment-variables: BACKEND_VERSION=${{ github.event.inputs.version }}

    - name: Deploy Amazon ECS task definition
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: ${{ steps.task-def.outputs.task-definition }}
        service: backend
        cluster: backend

Following semver, i've bumped the version on package.json to 1.1.0, as a new feature was added in a backward-compatible way.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[dspv]

Any news about this PR?

[BabyDino]

+1 looking forward to this one

[Misterio77]

Just waiting for a review

[efekarakus]

Hi @Misterio77 !

Looks great, apologies for the late review 🙇 some tiny suggestions below and then we can merge it!

[efekarakus]

This might be a very naive question 😅
But is it possible for environment-variables to be a map instead of a string?

Something like:

environment-variables:
   NAME: value
   FOO: bar

Assuming that's not possible, can we use comma "," as a separator instead of "|" that seems to be more common to split values?

environment-variables: "BUCKET=my-bucket,KEY=file.txt"

[Misterio77]

Sadly the inputs are always strings, as far as i know: https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#inputs

[Misterio77]

About the separator, i've seen a couple cases where environment variables contents might include commas, so i choose the pipe (which is not used, as to avoid problems with accidentally bash piping stuff) instead.

Maybe there's some way we can allow the users to escape the commas? But i personally think using pipes is easier and does not require the user to scan their variables looking for rogue commas.

[efekarakus]

Gotcha thanks the explanation makes sense! I'm still reluctant to use pipes as separator as it's so unusual 🤔
One other alternative, that I can think of is instead splitting on new lines like this if users want to define multiple:

environment-variables: |
   BUCKETS=my-bucket,my-other-bucket
   KEY=file.txt

https://github.community/t/can-action-inputs-be-arrays/16457/2 which seems to be a common approach with GH actions, and aligns well with the syntax of environment files.

We can then in the code do this: s.split('\n').map((line) => line.trim()).filter((pair) => !!pair)

Does that make sense?

[Misterio77]

This is a great idea, i think it looks great!

[Misterio77]

I'm not sure if we can (or should) write multi-line descriptions on action.yml, so i've documented the change, but without a "literal example".
Please let me know if it looks okay :))

[efekarakus]

Awesome, ty for the quick follow-ups! Looks great, I suggested some small wording change here: #114 (comment)

I think we're almost done!

[Misterio77]

Thanks a lot for the reviews!

[Misterio77]

No worries at all about the delay!
Thanks a lot for the review :)

[efekarakus]

Looks good! One last change sorry 🥺 and if we can fix the merge conflicts?

[efekarakus]

Woohoo!🥳

[Misterio77]

All squashed and rebased!
I left the version as 1.0.24, it seems the github action handles bumping?

[efekarakus]

Yay merged! Sorry it took a while because I don't have write permissions, so I had to chase after someone that could merge it :)

[Misterio77]

No problem at all! Thanks a lot

[robsonalves]

Hey guys, thanks for this rich contribution. @Misterio77 @efekarakus <3

but this new feature wasn't released yet, right?

The code was merged, but no one new version was released. I am just making a reminder, cause using the Commit Id Works fine!

Thanks again.

[benbonnet]

can confirm it is missing but thx to @robsonalves it works well with commit id

- name: some-name
   id: some-id
   uses: aws-actions/amazon-ecs-render-task-definition@85f5e350c104582a36945a4b66abdd29b42123bf
   with:
     task-definition: ${{ steps.rails-definition.outputs.task-definition }}
     container-name: some_container_name
     image: ${{ steps.build-image.outputs.image }}
     environment-variables: |
            SOME-VAR=${{ secrets.SOME_VAR }}