environment: with workflow_call

[dacbd]

I'm not sure if I'm doing something wrong or if environments just don't play nice with workflow_call

I have a generic job that performs various checks against a cloud provider. As input I have tried:
A) passing the options:

name: trigging workflow
on:
  workflow_dispatch:

jobs:
  check:
    environment: cloud_one
    uses: my-org/my-repo/.github/workflows/generic-check.yml@main
    with:
      count: 0
    secrets:
      token: ${{ secrets.cloud_token }}

name: triggered workflow
on:
  workflow_call:
    secrets:
      token:
        required: true
        type: string
    inputs:
      count:
        required: true
        type: number
jobs:
  check:
    runs-on: ubuntu-latest
    steps:

B) passing an environment string, (the environment contains the options/config items as a secret):

name: trigging workflow
on:
  workflow_dispatch:

jobs:
  check:
    uses: my-org/my-repo/.github/workflows/generic-check.yml@main
    with:
      myenv: cloud_one
      count: 0

name: triggered workflow
on:
  workflow_call:
    inputs:
      count:
        required: true
        type: number
jobs:
  check:
    # also test with a hardcoded value
    environment: ${{ inputs.myenv }}
    runs-on: ubuntu-latest
    steps:

both of these seem to not be working for me. Where A) gives an error like Unexpected value 'uses' .github/workflows/file.yml (Line: x, Col: x): Unexpected value 'with and B) doesn't seem to use the environment( values are blank).

Both workflows are in the same internal repo, and there are no environment protection rules.

Happy to try and provide any additional context that might be helpful.

[0x2b3bfa0]

Case A

Environments can only be specified in the triggered workflow, not in the triggering one. Hovering the red wavy underline will reveal a popup menu describing the cause of the error.

It would be nice to include this gotcha it in the limitations section of the official documentation.

Case B

Working example

.github/workflows/triggering.yml

on: workflow_dispatch
jobs:
  check:
    uses: user/repository/.github/workflows/triggered.yml@main
    with:
      environment: foo

.github/workflows/triggered.yml

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
jobs:
  check:
    environment: ${{ inputs.environment }}
    runs-on: ubuntu-latest
    steps:
    - run: echo ${{ inputs.environment }}

Cause of the issue

In your example above, there is no input declaration for myenv

[dacbd]

Sorry in the actual workflow that is present, but it seems that it doesn't actually use the environment, I'll put together a simple test.

[0x2b3bfa0]

Update: it does use the environment in the sense of requiring approvals before running, but secrets aren't being populated. 🙈

[dacbd]

That is the issue I found :)

[0x2b3bfa0]

See #1615 (comment) below. It's feasible, but not precisely intuitive.

[dacbd]

Not intuitive is correct

[0x2b3bfa0]

Example with environment secrets

Given an environment named example containing an environment secret named TOKEN, the following triggered workflow will have access to that secret:

.github/workflows/triggering.yml

on: workflow_dispatch
jobs:
  check:
    uses: user/repository/.github/workflows/triggered.yml@main
    with:
      environment: example
    secrets:
      token: ${{ secrets.TOKEN }}

.github/workflows/triggered.yml

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
    secrets:
      token:
        required: true
jobs:
  check:
    environment: ${{ inputs.environment }}
    runs-on: ubuntu-latest
    steps:
    - run: echo ${{ secrets.token }}

[dacbd]

https://github.com/0x2b3bfa0/reusable