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

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.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 9
  • Comments: 21

Commits related to this issue

Most upvoted comments

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

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

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

Link is broken 💔

@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 https://github.com/actions/toolkit/issues/931

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?

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?

We have something that looks like this, rather:

on:
  workflow_call:
    secrets:
      PASSWORD:
        required: true

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

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

@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:

Bildschirmfoto 2022-09-01 um 13 03 55

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.

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

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

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.

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

@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 😃