Passing in secrets to reusable workflow does not work without secrets in env

[martin-svanberg-northvolt]

We are trying out Github Actions and have run into a curious issue which we think is a bug. We have configured secrets at the organization level, and are trying to pass those secrets in to a reusable workflow as shown below:

name: example

on:
  pull_request:
    branches:
      - gh-actions

jobs:
  test:
    uses: northvolt/example/.github/workflows/review-common.yml@gh-actions
    secrets:
      password: ${{ secrets.PASSWORD }}

This does not work. password shows up blank in the reusable workflow instead of having the value of the secret.

If we instead add env: ${{ secrets }} to the top-level of the manifest, all of a sudden the secret gets passed in to the workflow. This seems quite counterintuitive since passing in secrets should not be related to the env, and this behavior does not appear to be documented anywhere. In fact, this example of secrets in reusable workflows does not need an env key set at the top-level.

[cloin]

Do you have something like this in review-common.yml ?

workflow_call:
    secrets:
      password:
        description: 'needed for login'
        required: false

[martin-svanberg-northvolt]

We have something that looks like this, rather:

on:
  workflow_call:
    secrets:
      PASSWORD:
        required: true

[cloin]

I posted about how I got this to work for me over here https://github.saobby.my.eu.orgmunity/t/reusable-workflows-secrets-and-environments/203695/26?u=cloin

[martin-svanberg-northvolt]

Thanks for the link @cloin!

[bobleujr]

@martin-svanberg-northvolt I also had this behavior trying to use an organization-level secret. It worked with a secret in the repo though. I feel like trying to guess how variables and secrets are organized and rendered across templates & actions is like navigating a sea in the dark. Azure DevOps (which is far from perfect) has A LOT to teach to github actions. If you guys want to give it a push, please comment / +1 this issue actions/toolkit#931

[ericsciple]

@martin-svanberg-northvolt i tried to reproduce the issue and it seems to be working correctly now.

We rolled out some recent fixes in related code, which perhaps fixed this issue as well :)

[martin-svanberg-northvolt]

Thanks @ericsciple! Closing this for now. Will reopen if there are further issues.

[param-finder]

Spent hours on this dreaded issue. CircleCI is so much better when it comes to re-usability. Github Actions lack good documentation and features!

[woutersf]

For future me:
secrets:inherit fixed it for me:
In the calling job:

jobs:  
  deploy-tst-custom:
    uses: ./.github/workflows/thejob.yml
    secrets: inherit

*edited typo

[M-Farag]

Yeah (secrets: inherit) did the trick to me.
Just add it to the caller workflow ;)

[rednevals]

Using secrets: inherit did allow for organization and repository secrets to be passed in, but not environment secrets. These are still unavailable. Anyone having this issue?

[jdjuan]

@rednevals, I found this article, and realized that you can pass the environment name as an input variable, and simply use environment inside the reusable workflow. It worked for me, see the screenshot below:

[flobernd]

Yeah, this is very unintuitive. Found this workaround myself a while ago, but I'm not happy with it. The secrets are passed by the caller and imho the same should be the case for the environment (as it is tightly bound to the secrets). Having to use a workaround like introducing a custom input, just does not feel right.

[rednevals]

I had opened a support ticket with GitHub and they explained it better... I was passing the environment in, but mistakenly trying to reference the value using "github.event.inputs.env" instead of "inputs.env". Ooops...

[3dfoster]

I posted about how I got this to work for me over here https://github.saobby.my.eu.orgmunity/t/reusable-workflows-secrets-and-environments/203695/26?u=cloin

Link is broken 💔

[cipherbullet]

Guys,
I'm using nested reusable workflows. Is there anyway to use github secrets without passing them in calling workflow?
I mean I wanna make my calling workflow as simple as possible.

[michaelpetri]

Guys, I'm using nested reusable workflows. Is there anyway to use github secrets without passing them in calling workflow? I mean I wanna make my calling workflow as simple as possible.

From the docs:

Workflows that call reusable workflows in the same organization or enterprise can use the inherit keyword to implicitly pass the secrets.

jobs:
  call-workflow-passing-data:
    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
    with:
      config-path: .github/labeler.yml
    secrets: inherit

[LucasMMota]

it looks Github Actions doesn't accept keyword PASSWORD.
I changed my secret in the file from SNOWFLAKE_PASSWORD to SNOWFLAKE_PWD and worked fine

[MDerrickGlass]

I'm missing something. I have reusable workflows where the secret is only relevant INSIDE the workflow. It seems from all the discussion that it's imperative to define the names of all POTENTIALLY USED secrets in all workflows a caller MAY call in the caller, then use secrets: inherit to pass the whole set to all the called workflows. However, the calling workflow doesn't KNOW what the called workflow may use, it's part of the desired isolation.

How can a reusable workflow simply reference the secrets collection to read/use an organization secret (without passing them in explicitly from the top and funneling them all the way through)? Resort to an API call?

[nullism]

How can a reusable workflow simply reference the secrets collection to read/use an organization secret (without passing them in explicitly from the top and funneling them all the way through)? Resort to an API call?

We also would like to do this. The caller doesn't know the secret, we simply want it defined on the repo containing the reusable workflow (or action).

[servandorodrigues]

How can a reusable workflow simply reference the secrets collection to read/use an organization secret (without passing them in explicitly from the top and funneling them all the way through)? Resort to an API call?

We also would like to do this. The caller doesn't know the secret, we simply want it defined on the repo containing the reusable workflow (or action).

Same issue here, my secret is under the called workflow not the one calling.

[42kbit]

@rednevals, I found this article, and realized that you can pass the environment name as an input variable, and simply use environment inside the reusable workflow. It worked for me, see the screenshot below:

Thanks, worked for me.

Without passed environment hack, the actions fails with log:

use_webserver_cd / Deploy to elastic beanstalk
Secret AWS_ACCESS_KEY is required, but not provided while calling.

Here is a snippet of code and what i did to fix it, if someone faces the same problem:

Caller code:

jobs:
  use_webserver_cd:
    uses: ./.github/workflows/webserver_cd_aws_ebs.yaml
    with:
      environment: 'prod'
    secrets: inherit

Reusable workflow

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string

jobs:
  deploy:
    name: Deploy to elastic beanstalk
    runs-on: ubuntu-latest
    environment: ${{ inputs.environment }}
    
    steps:
        # ... snip ...
      - name: Authenticate to aws account
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}
        # ... snip ...

Full commit files here:
Caller code
Reusable workflow code

[dankellett]

I was looking to have a step in a job to retrieve secrets from 1password and then pass them into the re-usable workflow. Looks like this doesn't have a clean solution given this gap in functionality.

[adamdicarlo0]

I posted about how I got this to work for me over here github.community/t/reusable-workflows-secrets-and-environments/203695/26?u=cloin

Dear GitHub: Sure would be nice if that link still worked 🤣😭