actions / toolkit

The GitHub ToolKit for developing GitHub Actions.
https://github.com/features/actions
MIT License
4.91k stars 1.4k forks source link

More documentation is needed on how variables/secrets are rendered/scoped across reusable workflows & actions #931

Open bobleujr opened 2 years ago

bobleujr commented 2 years ago

Hi community, I feel the need for better documentation on how variables are available, scoped, rendered across reusable workflows, actions, etc. It's almost a shot in the dark trying to get our values running through workflows.

Example 1 - ${{ github.workspace }}

In the workflow definition, ${{ github.workspace }} renders to nothing, example

jobs:
  job_name:
    uses: .../.github/workflows/template.yaml@pipelines
    with:
      workspace: ${{ github.workspace }} # This resolves to empty string

However, in the reusable workflow .../.github/workflows/template.yaml@pipelines, it renders the correct path

on:
  workflow_call:
    inputs:
      someArg:
        description: 'Some args'
        required: true
        type: string

jobs:
  ci:
    name: Build, test and push
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo ${{ github.workspace }} # This prints something

Then in the documentation for available environment variables, we see GITHUB_WORKSPACE as an available variable. How does GITHUB_WORKSPACE becomes this github.workspace, on which occasions? When are they available? Where? (this goes for everything github.*

Example 2 - Organization secrets

As stated here: https://github.com/actions/runner/issues/1413

Organization-level secrets aren't available in the caller workflow. But repo-specific repos are!

Example 3 - env at root is not available at any moment in the caller workflow

In the caller workflow, if env is defined at the root level of the framework, values aren't achievable anywhere within the jobs.<job_id>.with.

env:
   var1: 'value'

jobs:
  job_name:
    uses: .../.github/workflows/template.yaml@pipelines
    with:
      workspace: ${{ env.var1 }} # This doesn't work
      workspace: ${ var1 } # This doesn't work

Trying to access from the job definition is also invalid. * and doesn't allow for reuse of variables in different uses.

jobs:
  job_name:
    env: # This is invalid syntax
       var1: 'test' # This is invalid syntax
    uses: .../.github/workflows/template.yaml@pipelines
    with:
      workspace: ${{ github.workspace }} # This resolves to empty string

I mean, the list goes on. I have an entire document on how to rig solutions to get these values through, but I don't see it anywhere on the documentation. For instance, Azure DevOps has differences for ${{ var }} [ var ] $(var) . image

boeckMt commented 2 years ago

Are there any updates on this Issue?

bobleujr commented 2 years ago

not really :(

renny-oh commented 1 year ago

needs answer of this. please. this has been about a year.

anderssonw commented 1 year ago

Context availability is documented here. So it is documented, but not entirely obvious. @renny-oh

I still find it really odd that job.<job-id>.with cannot access env, whereas job.<job-id>.steps.with can.

DanielRailean commented 1 year ago

I also think this is much needed. The current way of passing env vars as input is cucumbersome at best.

michaelfecher commented 1 year ago

How can I access the organization-secrets in a called workflow of the same repo? As stated by OP, it works without any hassle for repository secrets. I added secrets: inherit already in the caller workflow.

sinux-l5d commented 1 year ago

Hi @anderssonw, any idea why job.<job-id>.with can't access env? It's seems indeed to be a weird behaviour. I'm currently stuck on something like example 3

anderssonw commented 1 year ago

Hi @anderssonw, any idea why job.<job-id>.with can't access env? It's seems indeed to be a weird behaviour. I'm currently stuck on something like example 3

@sinux-l5d I'm not affiliated with GitHub, just ran into the same problem and found the documentation earlier. No idea why it works this way.

sanjacob commented 1 month ago

@bobleujr Could you please share the document? This issue is still not resolved.