Actions: reusable workflow job fails before scheduling when passing a declared secret

[luketainton]

Gitea Version

1.27.2

What happened?

A job that calls an external reusable workflow fails during scheduling when the called workflow declares a secret and the caller passes that secret through jobs.<job_id>.secrets.

The job receives no runner, has no steps or log output, and fails before the called workflow's first step. Moving the secret-consuming step into a normal runs-on job in the caller succeeds.

Minimal reproduction

Caller workflow:

name: caller
on: workflow_dispatch

jobs:
  call:
    uses: https://gitea.example.test/shared/workflows/.gitea/workflows/reusable.yaml@main
    secrets:
      TEST_SECRET: ${{ secrets.TEST_SECRET }}

Called workflow:

name: reusable
on:
  workflow_call:
    secrets:
      TEST_SECRET:
        required: true

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - run: test -n "${{ secrets.TEST_SECRET }}"

Expected behaviour

The reusable-workflow job should be scheduled on a runner and receive the secret declared by on.workflow_call.secrets.

Actual behaviour

The caller job fails before a runner is assigned and before any steps run. There is no diagnostic explaining why the passed secret prevents scheduling.

Workaround

Perform the secret-consuming step in a normal job in the caller workflow.

[atiqur-rahman-pro]

Hi @luketainton! I would like to investigate this issue. I will reproduce it in Gitea 1.27.2, trace the reusable-workflow secret validation and scheduling path, and add a regression test that ensures that declared secrets are passing without being exposed in the logs. If the root cause is confirmed, I will submit a minimal fix. If anyone has already worked on this, please let me know. thank you.

[bircni]

https://blog.gitea.com/release-of-1.27.0/#%EF%B8%8F-improve-support-for-reusable-workflows-37478

This is wanted behaviour

Also see here --> #37478

[luketainton]

Thanks @bircni - I did see this but forgot about it 🙂 I'll update my repos and see if this fixes it.

[luketainton]

Confirmed - this (plus some missing workflow_call input type definitions) were the cause. Thanks again @bircni.