5

I have a reusable workflow for building and pushing a docker image to ECR.

One of the inputs of the workflow is for specifying arguments for the docker build command. This is the command in the reusable workflow:

docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG ${{ inputs.DOCKER_BUILD_ARGS }} .

In some cases, I need DOCKER_BUILD_ARGS to contain secrets, for example:

    secrets:
      AWS_ACCESS_KEY: ${{ secrets.AWS_ACCESS_KEY }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    uses: XXXXX/.github/workflows/DockerBuildPushECR.yml@main
    with:
      ECR_REGISTRY: XXXXXX
      ECR_REPOSITORY: XXXXX
      DOCKER_BUILD_ARGS: "--build-arg PASSWORD=${{ secrets.PASSWORD }}"

GitHub complains that the workflow is not valid: "Unrecognized named-value: 'secrets'", because it only expects secrets in the secrets section.

I cannot pass it as a secret because the reusable workflow does not expect this secret, I just want it to be part of the string...

Can't use env because it cannot be used in conjunction with a reusable workflow

How can I make this scenario work?

Mickey Cohen
  • 997
  • 7
  • 23
  • Actually, you can use `env` in reusable workflows, but you have to set the value inside the reusable workflow. In your case, I believe that setting `env: PASSWORD: ${{ secrets.PASSWORD }}` then using `with: DOCKER_BUILD_ARGS: "--build-arg PASSWORD=${{ env.PASSWORD }}"` should work. Let me know :) – GuiFalourd Sep 05 '22 at 11:16
  • Yes, that could work. However, this is for a specific secret. I am trying to make something more generic where the whole list of arguments can be different. Sometimes just plain text, sometimes with secrets, sometimes with different secrets – Mickey Cohen Sep 05 '22 at 12:00
  • Same issue here. Did you find a solution? – orkenstein Jan 13 '23 at 19:36
  • @orkenstein I just posted how I solved this for me, hope this helps you too – Mickey Cohen Jan 15 '23 at 14:15

1 Answers1

0

What I ended up doing is adding 2 optional secrets to the reusable workflow added them as build args in the docker build commnd. This way, if they are passed - they are secrets, and if they are not - they are simply blank and this does not affect anything. It solved my scenario.

So, the secrets section looked like this:

    secrets:
      AWS_ACCESS_KEY:
        required: true
      AWS_SECRET_ACCESS_KEY:
        required: true
      USERNAME:
        required: false
      PASSWORD: 
        required: false

and the build like this:

    - name: Build and tag image
      run: docker build -f ${{ inputs.DOCKERFILE }} -t ${{ inputs.ECR_REGISTRY }}/${{ inputs.ECR_REPOSITORY }}:${{ inputs.IMAGE_TAG }} --build-arg USERNAME=${{ secrets.USERNAME }} --build-arg PASSWORD=${{ secrets.PASSWORD }} ${{ inputs.DOCKER_BUILD_ARGS }} ${{ inputs.DOCKER_BUILD_CONTEXT }}

Of course, the Dockerfile needs to have corresponding arguments. This allowed me to pass up to 2 secrets "dynamically"

Mickey Cohen
  • 997
  • 7
  • 23