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

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

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:

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 😃