OpenID Credential Configuration about invoke-aws-lambda HOT 6 OPEN

Hey @stefenAMZ and @gagoar, I was able to do this by using the env variables set by the "aws-actions/configure-aws-credentials@v1"

      - name: Assume AWS role
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: the_arn_of_the_role_you_want_to_assume
          aws-region: eu-west-1

      - name: Invoke the Lambda
        uses: gagoar/invoke-aws-lambda@master
        with:
          AWS_ACCESS_KEY_ID: ${{env.AWS_ACCESS_KEY_ID}}
          AWS_SECRET_ACCESS_KEY: ${{env.AWS_SECRET_ACCESS_KEY}}
          AWS_SESSION_TOKEN: ${{env.AWS_SESSION_TOKEN}}
          REGION: ${{env.AWS_REGION}}
          FunctionName: foobarFunction
          Payload: '{ "myParameter": false }'

from invoke-aws-lambda.

Hey @stefenAMZ Lemme see how I can implement that.

from invoke-aws-lambda.

@gagoar the thing is that this definition is kind of duplicate, aws-cli can automatically detect the env variables if they are configured with `"aws-actions/configure-aws-credentials@v3" which is what everyone is opting towards now, short lived session token credentials.

I think in addition to the documentation change, the then there isn't any need to even define AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY and they shouldn't be a required variables even.
If someone does need to define them similarly to now they can do it in the env portion versus the with now.
i.e. 2 scenarios:

#1

      - name: Assume AWS role
        uses: aws-actions/configure-aws-credentials@v3
        with:
          role-to-assume: the_arn_of_the_role_you_want_to_assume
          aws-region: us-east-1

      - name: Invoke the Lambda
        uses: gagoar/invoke-aws-lambda@master
        with:
          REGION: ${{env.AWS_REGION}}
          FunctionName: foobarFunction
          Payload: '{ "myParameter": false }'

#2 - people not using configure aws creds

      - name: Invoke the Lambda
        uses: gagoar/invoke-aws-lambda@master
        env:
          AWS_ACCESS_KEY_ID: ${{env.AWS_ACCESS_KEY_ID}}
          AWS_SECRET_ACCESS_KEY: ${{env.AWS_SECRET_ACCESS_KEY}}
        with:
          REGION: ${{env.AWS_REGION}}
          FunctionName: foobarFunction
          Payload: '{ "myParameter": false }'

since its not fully backward compatible, might need to release an updated version of this
also its better in the documentation and examples to let people refer to the action at a specific tag/version and not to master, like in this case it may break some use cases, actually maybe if you just keep the variables definitions but not make them required this may not break

from invoke-aws-lambda.

Thank you @thenanor! So the action configure-aws-credentials will provide the necessary envs after invoking it? That's very convenient.

We just need to document this in the readme. @stefenAMZ does this will satisfy your request?

from invoke-aws-lambda.

@gagoar the thing is that this definition is kind of duplicate, aws-cli can automatically detect the env variables if they are configured with `"aws-actions/configure-aws-credentials@v3" which is what everyone is opting towards now, short lived session token credentials.

I think in addition to the documentation change, the then there isn't any need to even define AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY and they shouldn't be a required variables even. If someone does need to define them similarly to now they can do it in the env portion versus the with now. i.e. 2 scenarios:

#1

      - name: Assume AWS role
        uses: aws-actions/configure-aws-credentials@v3
        with:
          role-to-assume: the_arn_of_the_role_you_want_to_assume
          aws-region: us-east-1

      - name: Invoke the Lambda
        uses: gagoar/invoke-aws-lambda@master
        with:
          REGION: ${{env.AWS_REGION}}
          FunctionName: foobarFunction
          Payload: '{ "myParameter": false }'

#2 - people not using configure aws creds

      - name: Invoke the Lambda
        uses: gagoar/invoke-aws-lambda@master
        env:
          AWS_ACCESS_KEY_ID: ${{env.AWS_ACCESS_KEY_ID}}
          AWS_SECRET_ACCESS_KEY: ${{env.AWS_SECRET_ACCESS_KEY}}
        with:
          REGION: ${{env.AWS_REGION}}
          FunctionName: foobarFunction
          Payload: '{ "myParameter": false }'

since its not fully backward compatible, might need to release an updated version of this also its better in the documentation and examples to let people refer to the action at a specific tag/version and not to master, like in this case it may break some use cases, actually maybe if you just keep the variables definitions but not make them required this may not break

I understand. What if we add a new parameter so the passed credentials, as we usually do, aren't needed? Would that sort out your use case?

I'm thinking an option like OPEN_ID_ENABLED=boolean

from invoke-aws-lambda.

@gagoar The thing is that this definition is kind of duplicate, aws-cli can automatically detect the env variables if they are configured with "aws-actions/configure-aws-credentials@v3" which is what everyone is opting towards now, short lived session token credentials. I think in addition to the documentation change, the then there isn't any need to even define AWS_ACCESS_KEY_IDandAWS_SECRET_ACCESS_KEYand they shouldn't be arequiredvariables even. If someone does need to define them similarly to now they can do it in theenvportion versus thewith` now. i.e. 2 scenarios:
#1

      - name: Assume AWS role
        uses: aws-actions/configure-aws-credentials@v3
        with:
          role-to-assume: the_arn_of_the_role_you_want_to_assume
          aws-region: us-east-1

      - name: Invoke the Lambda
        uses: gagoar/invoke-aws-lambda@master
        with:
          REGION: ${{env.AWS_REGION}}
          FunctionName: foobarFunction
          Payload: '{ "myParameter": false }'

#2 - people not using configure aws creds

      - name: Invoke the Lambda
        uses: gagoar/invoke-aws-lambda@master
        env:
          AWS_ACCESS_KEY_ID: ${{env.AWS_ACCESS_KEY_ID}}
          AWS_SECRET_ACCESS_KEY: ${{env.AWS_SECRET_ACCESS_KEY}}
        with:
          REGION: ${{env.AWS_REGION}}
          FunctionName: foobarFunction
          Payload: '{ "myParameter": false }'

since its not fully backward compatible, might need to release an updated version of this also its better in the documentation and examples to let people refer to the action at a specific tag/version and not to master, like in this case it may break some use cases, actually maybe if you just keep the variables definitions but not make them required this may not break

I understand. What if we add a new parameter so the passed credentials, as we usually do, aren't needed? Would that sort out your use case?

I'm thinking an option like OPEN_ID_ENABLED=boolean

I don't want to break functionality with the older implementations. There are lots of repositories using @master straight up at the moment.

from invoke-aws-lambda.