runner: github context is not accessible from step.uses

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

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

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.

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.

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.community/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. 😄

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 }}"

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 }'

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?

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

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

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.

😞

@chrispat from product

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.community/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?