Environment Secrets are not available on Reusable Workflow / Workflow Templates
See original GitHub issueDescribe the bug
obs: this feature works as designed, but I believe it could be improved.
Problem: Passing an environment containing secrets to a reusable workflow is not enough to have the environment secrets avaiable.
Example: In a repository, there is an environment called “myenv”, which contains a single secret called “MY_SECRET”. In this repository, there is also a workflow calling a reusable workflow.
This is the reusable workflow
name: Reusable Workflow
on:
workflow_call:
inputs:
ENVIRONMENT:
required: true
type: string
jobs:
some-job:
runs-on: ubuntu-latest
environment: ${{ inputs.ENVIRONMENT }}
steps:
- run: env
And this is the workflow
name: Workflow Caller
on:
push:
branches:
- **
jobs:
some-job:
uses: Org/repo/.github/workflows/reusable-workflow.yml
with:
ENVIRONMENT: myenv
When running this workflow, MY_SECRET
isn’t available. I see something like this in the logs:
...
MY_SECRET:
...
instead of this
...
MY_SECRET:***
...
In order to make MY_SECRET
available in the reusable workflow, I must explicitly write it in the workflow caller, like so:
name: Workflow Caller
on:
push:
branches:
- **
jobs:
some-job:
uses: Org/repo/.github/workflows/reusable-workflow.yml
with:
ENVIRONMENT: myenv
secrets:
MY_SECRET: ${{ secrets.MY_SECRET }}
Why can’t the reusable workflow load all of the environment secrets automatically using just the environment’s name? Is there a reason for not doing it?
In this repo you can find all of my experiments: https://github.com/AllanOricil/workflow-template-bug
Expected behavior “Deployment Environment” secrets should be available in reusable workflows
What’s not working?
“Deployment Environment” secrets are not available in reusable workflows
Job Log Output
...
MY_SECRET:
...
Issue Analytics
- State:
- Created 2 years ago
- Reactions:37
- Comments:37 (2 by maintainers)
Top GitHub Comments
It would be great if GitHub allows us to use environment with reusable workflows in an intuitive way with good documentation.
Can this please be re-opened? This is just extremely inefficient and resulted in me having to move our deployment steps into the release steps workflow file which is unpleasant to look at and couples our entire release pipeline too closely together from a structural point of view.
How Github thought this was acceptable is beyond me.