github context is not accessible from step.uses

[igagis]

Describe the bug
It is not possible to use github context in jobs.<job_id>.steps[*].uses.

To Reproduce
create workflow which uses github context within uses:

name: ci
on: [push, pull_request]
jobs:
  my_job:
    runs-on: ubuntu-latest
    steps:
      - name: this repo action
        uses: ${{ github.repository }}@${{ github.sha }}        

Expected behavior
github.repository and github.sha are substituted with correspoonding values.

Runner Version and Platform

public runner

What's not working?

github context variable substitution

Job Log Output

The workflow is not valid. .github/workflows/ci.yml (Line: 17, Col: 15): Unrecognized named-value: 'github'. Located at position 1 within expression: github.repository 

Runner and Worker's Diagnostic Logs

https://github.com/myci-actions/add-deb-repo/actions/runs/469160309

[michalinacienciala]

Same issue occurs also for steps context.

[TingluoHuang]

We don't support expression in those place, you need to checkout the repo to use local action.

- uses: actions/checkout@v2
- uses: ./

[TingluoHuang]

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-using-action-in-the-same-repository-as-the-workflow

[igagis]

Is there a reason why it is not supported?

[TingluoHuang]

We want the YAML file readable at some level, so we don't open expressions for every part of the YAML file.

You can make a feature request at https://github.jparrowsec.cnmunity/c/code-to-cloud/github-actions/41

The runner repo might not be a good place for this kind of question, it doesn't understand YAML at all, the service parses the YAML and validates against a defined schema. 😄

[igagis]

We want the YAML file readable at some level, so we don't open expressions for every part of the YAML file.

This looks to me as a pretty weak argumentation.

You can make a feature request at https://github.jparrowsec.cnmunity/c/code-to-cloud/github-actions/41

I find forums pretty bad place for feature requests, as the post on forums quickly gets lost and nobody follows up on those. There should be a bug tracker for that! This is why I opened it here. I have no idea which part of the software is responsible for yaml parsing, could you forward this to the right team/software component?

[TingluoHuang]

@chrispat from product

[chrispat]

The original reason we didn't support it was so we could enforce the policies of the org when they limited which actions you could use. We have changed how the runner resolves actions so it we could support it now. However, you would get a runtime failure if you violated a policy rather than a queue time failure.

For this particular scenario I don't see how it is different than referencing a repository local action via ./

[igagis]

Ok, for my particular use case using local action is enough, so if you want, you can close the issue.

[groensch24]

We want to have a security check of you containers implemented for every PR that is created.

For that it is crucial to build the container in one job, push it into the registry and then pull and run some command in it.

jobs:
  security-check:
    runs-on: ubuntu-latest
    needs: build-main-test
    steps:
      #....
      - uses: docker://eu.gcr.io/security-check:${{ env.GITHUB_SHA }}
        with:
          entrypoint: security-check

How can we achieve this when we cannot use the variables in this context?

[spangaer]

If you try access a sibling action that you want to have at the same ref as the action being executed you need that expansion too.

😞

[cyechow]

If we have a checkout action that sets a path relative to GITHUB_WORKSPACE and then want to call a custom action, is there a way to do this?

I've tried various things and haven't found a method that works.

env:
  GIT_CLONE_PATH: "${{ github.workspace }}\\${{ github.ref_name }}"

jobs:
  test:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v3
        with:
          lfs: true
          clean: false
          path: "${{ env.GIT_CLONE_PATH }}"
# The following doesn't work because it's looking for actions.yml in ${{ github.workspace }}/.github/actions/CustomAction.
# We also can't set the working directory for uses.
      - uses: ./.github/actions/CustomAction 
# Ideally I can do something like this:
      - uses: "${{ env.GIT_CLONE_PATH }}/.github/actions/CustomAction"
# Or something like this:
      - uses: ./.github/actions/CustomAction 
        working-directory: "${{ env.GIT_CLONE_PATH }}"

[spangaer]

Try ./${{ github.ref_name }}/.github/actions/CustomAction

When using local actions the local action is indicated by the ., but the . equates to ${{ github.workspace }}

I do fear that the uses will not accept any ${{...}} so you you'll have to check out to my-code and then call ./my-code/.github/actions/CustomAction

I'd avoid using that ref name in check-paths. I guess there some dodging there of the self-hosted runner not cleaning up.

[wheelerlaw]

Lets say I have two repos. Repo A has a workflow that calls Composite Action 1 in Repo B. Composite Action 1 calls Composite Action 2 in Repo B.

The lack of availability of the github context object means that a composite action cannot use another composite action unless the branch is hard coded.

In Composite Action 1, I want to have the following:

uses: ./composite-action-2

However, I can't because the . resolves to the workspace of the calling workflow (which defaults to the root of the repo, Repo A), not the root of the repo where the composite actions are located, Repo B.

My first instinct is to do this:

uses: ${{ github.action_path }}/../composite-action-2

However, the github object is not available. I also can't do this:

uses: Org/repo-b/composite-action-2@${{ github.action_ref }}

Instead, I have to hard code the reference to the nested composite action, which greatly complicates the development workflow for working on these shared actions.

[jenseng]

I've figured out a workaround using a composite action that generates and runs another composite action to call the desired action dynamically 😅 ... Give jenseng/dynamic-uses@v1 a spin (or feel free to borrow/fork/adapt its action.yml)

Given a step like so:

- uses: actions/setup-node@v3
  with:
    node-version: 18

If you want your uses to be dynamic you can do:

- uses: jenseng/dynamic-uses@v1
  with:
    # now you can use expressions 🥳
    uses: actions/setup-node@${{ inputs.version }}
    # the `with` needs to be converted to a valid json string
    with: '{ "node-version": 18 }'

[joshua-alday]

@wheelerlaw this is my exact use case that I'm slamming my head against. Why is this not supported? I can hard code everything, but can't use github context to make it dynamic. Really under developed feature here guys.

[briferz]

Agreed. I would love to have this feature so that we at our organization are able to port workflows across GitHub organizations 😞

[elProxy]

The original reason we didn't support it was so we could enforce the policies of the org when they limited which actions you could use. We have changed how the runner resolves actions so it we could support it now. However, you would get a runtime failure if you violated a policy rather than a queue time failure.

For this particular scenario I don't see how it is different than referencing a repository local action via ./

In addition to the list of legit use cases pointed out above. One could structure a repo containing both reusable workflows and actions, and might want to guarantee the version of the actions used remains in sync with the reusable workflow, having access to github.job_workflow_sha could be pretty useful.

[adam-rummer-hpe]

In addition to the list of legit use cases pointed out above. One could structure a repo containing both reusable workflows and actions, and might want to guarantee the version of the actions used remains in sync with the reusable workflow, having access to github.job_workflow_sha could be pretty useful.

This is exactly our use case, it's disappointing it isn't supported

[SleepyBrett]

Why is this issue closed and not being actively worked on? This is a huge problem for testing new versions of actions that are nested deeply inside other actions.

if action A uses action B uses action C, in order to test my changes in action C I have to make a branch in action B that points to my commit on action C, and likewise in A.. what a fucking mess that is.

[cmergenthaler]

We are facing the exact same issue when trying to build unified actions & workflows for hundreds of repos within our orga. Having the github context available in steps.uses would simplify a lot in our setup

[mountHouli]

Hi GitHub Actions Runner Maintainers!

I do software development for the Department of Veterans Affairs.

First, I want to say thank you for all the work you do to build this product that thousands of us use every day to get our work done!

Regarding issue at hand, I'm also running into it!

I have a chunk of work that's implemented in Repo A workflow A.1 that calls Repo B Action B.1, and then Action B.1 calls workflow B.2.

As I make changes to workflow B.2 on my feature branch in repo B, I want to be able to iteratively test it by kicking off workflow A.1, in which I would like to be able to specify

    steps:
      uses: my-org/repo-b/.github/actions/action-b-1@${{ inputs.repo-b-branch }}

Important additional constraint:

In my use case, I can't do the suggested solution above of just checking out the version of repo-b we want. Here's why: In our case, Repo A needs to publish documentation to a website that Repo B has the secrets for. (And we have lots of repos like A, managed by various teams, that have to call Repo B to get their docs all published to the same customer support website that repo B controls.) Therefore, we can't just have action-a-1 directly and only employ the solution of checking-out-repo-b-feature-branch PLUS uses: workflow-b-2. Instead, our action-b-1 employs https://github.com/Codex-/await-remote-run to kick off workflow-b-2 in the execution context of our repo-b.

Please open this issue and work it into your roadmap.

[airtonix]

Hi GitHub Actions Runner Maintainers!
...
Please open this issue and work it into your roadmap.

@mountHouli Does your department have an enterprise or special relationship that it can leverage to lean on github to get this feature moving again?

I fear that posting requests like that here will just be ignored. If you have side channels that can be used to create "imaginative" motivation; I'm sure we would all be grateful.

Otherwise perhaps #895 (comment) will solve your issue?