Enhancement: Streamlining secret inheritance to environment in reusable workflows

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

1. Create a reusable workflow which references a secret defined in the secrets field under on: workflow_call.
2. In a separate repository (caller workflow), use this reusable workflow and include the secrets: inherit clause.
3. 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:

Caller Workflow:

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

Reusable Workflow:

name: Reusable Workflow Example

on: workflow_dispatch

jobs:
  triage:
    runs-on: ubuntu-latest
    env:
      DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
    steps:
      - name: Execute Test
        run: npm test

Application Test Code (Node.js):

const assert = require('assert');

// Test to ensure that the DB_PASSWORD is available and its length is sufficient
assert(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 issue names a caller workflow, reusable-workflow.yml, and a Node.js application test, but no runner source file or existing test. Start by locating the reusable-workflow handling and tests for secrets: inherit. Done means inherited secrets are available as requested without explicit declarations, while preserving the existing caller and reusable workflow behavior.