The first one doesn’t work because you’re trying to call the reusable workflow in a step, which isn’t possible (that’s for custom actions). A reusable workflow must be called at the job level.

Point three under Using inputs and secrets in a reusable workflow has an example. I notice it also says there:

Workflows that call reusable workflows in the same organization or enterprise can use the inherit keyword to implicitly pass the secrets.

I hope that doesn’t mean you can’t use that for workflows owned by the same personal account.

This is not possible. Using the GitHub Actions for VSCode extension, I have tried this approach:

secrets:
  inherit: true
  VERCEL_PROJECT_ID: "..."

I got this error:

Invalid secret, inherit is not defined in the referenced workflow.

Then, I tried this approach:

secrets: "inherit"
secrets:
  VERCEL_PROJECT_ID: "prj_1hHpDxBdgIZYX1MSlwrXWFpMFOlm"

And for this, I have gotten this error:

secrets is already defined

There's also this GitHub discussion that suggest that the choice between inherited secrets and explicit secrets is an either/ or kind of thing:

https://github.com/orgs/community/discussions/23107#discussioncomment-5707861

Check if the new (May 2022) keyword secrets: inherit can help:

GitHub Actions: Simplify using secrets with reusable workflows

GitHub Actions simplifies using secrets with reusable workflows with the secrets: inherit keyword.

Previously when passing secrets to a reusable workflow, you had to pass each secret as a separate argument.

Now you can simply pass the secrets: inherit to the reusable workflow and the secrets will be inherited from the calling workflow.

Learn more about reusable workflows in GitHub Actions and jobs.<job_id>.steps[*].uses.

In the reusable workflow, reference the input or secret that you defined in the on key in the previous step.

If the secrets are inherited using secrets: inherit, you can reference them even if they are not defined in the on key.

jobs:
 reusable_workflow_job:
   runs-on: ubuntu-latest
   environment: production
   steps:
     - uses: ./.github/workflows/my-action
       with:
         username: ${{ inputs.username }}
         token: ${{ secrets.envPAT }}

In the example above, envPAT is an environment secret that is been added to the production environment. That environment is therefore referenced within the job.

Note: Environment secrets are encrypted strings that are stored in an environment that you have defined for a repository. Environment secrets are only available to workflow jobs that reference the appropriate environment. For more information, see "Using environments for deployment."

Again, see jobs.<job_id>.steps[*].uses for additional examples.

As noted by wkhatch in the comments:

I do not believe this syntax is correct for using a reusable workflow, but is correct for using reusable actions. You cannot call a reusable workflow as a step, but you can with an action.

March 2025: As noted by Mickael V.'s comment, if you rely only on secrets: inherit without further organization, you would indeed have to set the secrets individually in all calling repositories... which does not scale well.

Sept. 2025: tamas.kenez comments that the caller job that uses a reusable workflow supports only with: and secrets:. Putting environment: there triggers Unexpected value 'environment'.

That means you would need to put environment: inside the called workflow's own job(s).

As an example of a reusable (called) workflow in a central repository (using here slackapi/slack-github-action:

# secrets-repo/.github/workflows/slack-notify.yml
name: Notify Slack

on:
  workflow_call:
    inputs:
      message:
        required: true
        type: string

jobs:
  notify_slack:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Send Slack notification
        uses: slackapi/slack-github-action@v2
        with:
          channel-id: ${{ secrets.SLACK_CHANNEL_ID }}
          slack-message: ${{ inputs.message }}
        env:
          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}

Called by:

# any-repo/.github/workflows/notify.yml
name: Call central Slack notify

on:
  push:
    branches: [ main ]

jobs:
  notify:
    uses: my-org/secrets-repo/.github/workflows/slack-notify.yml@main
    with:
      message: "Build successful"
    secrets: inherit

Kaspar H comments: "secrets resolve to the caller's repo, not the called repo"

That seems to be the default with reusable workflows (and with secrets: inherit): the called workflow receives the caller's secrets. To centralize secrets once and avoid per-repo duplication, keep them as environment secrets in the called repo, and make the called workflow's jobs declare environment:.

Late answer, but maybe it will help someone. This assumes that the secret value is set statically in the repo and not dynamically generated.

You can pass in the name of the secret as an input to the reusable workflow, and then access that secret using the secrets context and the secret name in brackets []:

${{ secrets[inputs.secret-name-input] }}

This also keeps the secret safe since you're only passing in the name of it.

So in your case, the workflows would be updated like this:

C:

name: Reusable workflow
on:
  workflow_call:
    inputs:
      secret-100-name:
        type: string

env:
  SECRET_1: ${{ secrets.SECRET_1 }}
  SECRET_2: ${{ secrets.SECRET_2 }}
  ...
  SECRET_100: ${{ secrets[inputs.secret-100-name] }}
jobs:
   ...

A:

name: Workflow A
on: ["workflow_dispatch"]

jobs:
  C:
    uses: ./.github/workflows/C.yaml
    with:
      secret-100-name: SECRET_100_FOR_A # DEFINE A SECRET IN THIS REPO NAMED `SECRET_100_FOR_A`
    secrets: inherit
    
jobs:
   ...

B:

name: Workflow B
on: ["workflow_dispatch"]

jobs:
  C:
    uses: ./.github/workflows/C.yaml
    with:
      secret-100-name: SECRET_100_FOR_B # DEFINE A SECRET IN THIS REPO NAMED `SECRET_100_FOR_B`
    secrets: inherit

jobs:
   ...