Skip to content

stuff #1

Description

@wechuli

Hi,

Here is what my reproduction yields:

The only secret that is passed from the TestEnvironment environment is WRONG_VALUE which has a value of Wrong but is passed down as TEST_SECRET:

In test_parent.yml you have:

  Job2:
    uses: ./.github/workflows/test_child.yml
    needs:
      - Job1
    secrets:
      TEST_SECRET: ${{ secrets.WRONG_VALUE }}

And in test_child.yml you have:

on: 
  workflow_call:
    secrets:
      TEST_SECRET:
        required: true

jobs:
  Job1:
    runs-on: ubuntu-latest
    environment: TestEnvironment

So in the reusable workflow, we expect secrets.TEST_SECRET to have the value of Wrong and secrets.WRONG_VALUE to be empty.

The secrets set in the environment as a part of Job1 ARE making it into Job2.

Could you let me know how you are testing this? The example you have references the TestEnvironment both in Job1 of the reusable workflow(test_child.yml) and Job1 of the caller workflow(test_parent.yml). Here is a reproduction using the provided workflows but in this case, I've removed the reference to the TestEnvironment in the job in the reusable workflow (test_child.yml) and retained that reference in Job1 of the caller workflow:

In this case, secrets.TEST_SECRET is empty (so is secrets.WRONG_VALUE ) as expected.

In the case of a secret being defined inside an environment, this is not possible. An "environment" can not be specified in the same job as a "uses". Therefor, you can not pass down the secret to the sub workflow using the syntax you specified.

Please note that the reference to the environment is done on the reusable workflow (not the caller workflow). The caller workflow only passes down these secrets through the secrets key at the job level(it has to explicitly do that). I've attached the two workflows and edited them to show how you can pass both of those secrets on the TestEnvironment environment from the caller workflow to the reusable workflow.

Does this help explain what you are observing?

Regards,
Paul
GitHub Support

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions