Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bobleujr opened this issue Oct 29, 2021 · 9 comments
Labels
enhancement New feature or request

Comments

@bobleujr
Copy link

bobleujr commented Oct 29, 2021

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: actions/runner#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
Copy link

boeckMt commented Dec 17, 2021

Are there any updates on this Issue?

@bobleujr
Copy link
Author

not really :(

@renny-oh
Copy link

renny-oh commented Nov 15, 2022

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

@anderssonw
Copy link

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
Copy link

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

@michaelfecher
Copy link

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
Copy link

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
Copy link

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

8 participants