You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when using reusable workflows in GitHub Actions, there is a complexity in passing secrets to these workflows. Even with the use of secrets: inherit, secrets still require explicit referencing in the reusable workflow file to be passed into the reusable workflow’s environment, which complicates scenarios where multiple applications with distinct secrets utilize a common reusable workflow.
Steps to Reproduce:
Create a reusable workflow which references a secret defined in the secrets field under on: workflow_call.
In a separate repository (caller workflow), use this reusable workflow and include the secrets: inherit clause.
Observe that unless the secret is explicitly declared in the reusable workflow, it is not available to the job.
🤔 Current Behavior:
Here's an example illustrating the current way we're required to pass a secret from the caller workflow to the reusable workflow:
constassert=require('assert');// Test to ensure that the DB_PASSWORD is available and its length is sufficientassert(process.env.DB_PASSWORD.length>5);
*I've added the necessary secret (DB_PASSWORD) to my GitHub application repository secret store, and I generally use GitHub environments for segregating secrets based on deployment stages or environments.
Context and Use Cases:
In an organization with multiple applications using a common deployment process, there is a need for a reusable workflow that can work with application-specific secrets like DB_PASSWORD, API_KEY, etc. The requirement to explicitly list each secret in every reusable workflow's definition becomes a maintenance burden.
✨ Desired Behavior / Feature Request:
Ideally, secrets passed with secrets: inherit should be automatically available to the reusable workflows without the need for explicit environment variable declaration within the reusable workflow’s env section.
This enhancement would significantly benefit those of us who maintain multiple related workflows across different projects, each requiring access to their unique set of secrets.
The text was updated successfully, but these errors were encountered:
🔍 Issue Description:
Currently, when using reusable workflows in GitHub Actions, there is a complexity in passing secrets to these workflows. Even with the use of
secrets: inherit
, secrets still require explicit referencing in the reusable workflow file to be passed into the reusable workflow’s environment, which complicates scenarios where multiple applications with distinct secrets utilize a common reusable workflow.Steps to Reproduce:
🤔 Current Behavior:
Here's an example illustrating the current way we're required to pass a secret from the caller workflow to the reusable workflow:
Caller Workflow:
Reusable Workflow:
Application Test Code (Node.js):
*I've added the necessary secret (
DB_PASSWORD
) to my GitHub application repository secret store, and I generally use GitHub environments for segregating secrets based on deployment stages or environments.Context and Use Cases:
In an organization with multiple applications using a common deployment process, there is a need for a reusable workflow that can work with application-specific secrets like DB_PASSWORD, API_KEY, etc. The requirement to explicitly list each secret in every reusable workflow's definition becomes a maintenance burden.
✨ Desired Behavior / Feature Request:
Ideally, secrets passed with
secrets: inherit
should be automatically available to the reusable workflows without the need for explicit environment variable declaration within the reusable workflow’senv
section.This enhancement would significantly benefit those of us who maintain multiple related workflows across different projects, each requiring access to their unique set of secrets.
The text was updated successfully, but these errors were encountered: