Reusable Workflows - predefined variables load for the called job

[orizerah]

Describe the bug
The environment variables that the runner loads contain information only about the called job and not about the caller.
For example: Assuming we have a workflow with a job build, which uses another workflow with a job called test, the job name in GitHub will be build / test, but the value of GITHUB_JOB will be test.
This denies me from having access in runtime to data about the job.

To Reproduce
Steps to reproduce the behavior:
Go to a GitHub repository and create 2 workflows:
called.yaml

name: Called
on: workflow_call
jobs:
  child:
    runs-on: ubuntu-latest
    steps:
       - name: Print Envs
         runs: prinenv

caller.yaml

name: Caller
on: workflow_dispatch
jobs:
  parent:
  uses: ./.github/workflows/called.yaml

Expected behavior
There should be a GITHUB_JOB_ID env with the correct job id
The GITHUB_JOB env should include the full name of the actual job.

Runner Version and Platform

ubuntu-latest

[ruvceskistefan]

Hey @orizerah,

you can pass values from parent to child as described in docs

reusable workflow

jobs:
  reusable_workflow_job:
    runs-on: ubuntu-latest
    environment: production
    steps:
    - uses: actions/labeler@v4
      with:
        repo-token: ${{ secrets.envPAT }}
        configuration-path: ${{ inputs.config-path }}

caller workflow

jobs:
  call-workflow-passing-data:
    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
    with:
      config-path: .github/labeler.yml
    secrets:
      envPAT: ${{ secrets.envPAT }}

[Felixoid]

I personally don't consider passing manual values down the road as a solution. The GITHUB_JOB has a completely meaningless value, when another workflow is called.

Let's open the API for the workflow jobs. Please, find the value "Debug / DebugInfo" there. Now, let's go to the logs of the running, and see what's there. It's DebugInfo. Ok. Could you anyhow from the given other ENV values combine the same thing, as given here? I doubt so.

The given problem causes the same issue, as the ticket reporter described. We can't get the GITHUB_JOB_ID automatically from existing information.

But if we have had a way to do so with a nasty boilerplate-styled workflows by searching GITHUB_JOB name in the mentioned API actions' runs/jobs, the issue prevents us from introducing reusable workflows.

[Felixoid]

According to docs, GITHUB_JOB represents the jobs.<job_id>. So it doesn't really look like a bug from this perspective.

Although, the mentioned issue still remains. There's no way to identify the full job name ParenId / SubsequentId / FinalReusableId in case of a complex pipeline.

A new GITHUB_COMPLETE_JOB looks like a good compromise, that wouldn't break existing users and would give a way to identify the full job name to find it in workflow-job API.

Another useful environment, that isn't present for ages already, is GITHUB_JOB_ID. Not sure if one even would need GITHUB_COMPLETE_JOB when the last is present automatically 🤔

[Felixoid]

There's a discussion hanging forever for the same issue https://github.com/orgs/community/discussions/8945

[Felixoid]

I don't consider it completed, and the decision to close it is entirely unclear.

It's one of the many examples showing the actions is a 3rd class citizen for GitHub.