Calling a sibling composite action using the same ref

[oblivioncth]

Select Topic Area

Suggestion

Body

NOTE: I completely worked this question to be a suggestion, as after some investigation I don't believe there is anyway to do this currently (at least in a sensible way).

If you have a repository dedicated to holing (composite) actions, like so:

repo_actions/
├── cp_action01/
│   └── action.yml
├── cp_ction02/
│   └── action.yml
└── ...

a common scenario is having the actions leverage other composite actions within the same repository.

repo_cactions/cp_action01/action.yml:

name: 'Composite action 01'
description: 'Example'
author: 'oblivioncth'
runs:
  using: 'composite'
  steps:
  - name: Call another composite action
    uses: oblivioncth/repo_cactions/cp_action02@main

The problem with doing this as shown, is that since the path/ref for the sub-action is hardcoded, that version will obviously always be used. This has the major downside of picking between two evils:

1. All nested calls to other composite actions must use the same ref/branch (and therefore you must essentially give up versioning)
   or
2. Use a specific ref for all nested calls, leading to the need for consumers to checkout multiple copies of your repository even if they intended to just use one version, potentially to a seriously inefficient degree if the size of the repository and variety of "inner" tags used grow large enough.

A more sensible design pattern would be to have any nested calls to composite actions within the same repository use the same ref that the outer most call received.

So in the above example, if 'cp_action01' was used from an external repository like so:
uses: oblivioncth/repo_cactions/cp_action01@v1.0
then the use of 'cp_action02' within would also be via tag v1.0.

You would think you could do this by doing the following in the outer action

...
  steps:
  - name: Call another composite action new method
    uses: ${{ github.action_repository }}/cp_action02@${{ github.action_ref }}

but you can't because steps.uses cannot access the github context.

It is technically possible to work around this by having the outer action checkout the repository with the same ref (redundantly) to a hard-coded path and then invoke the action as a local one, but this adds a ton of extra boilerplate to each composite action and pollutes the consumers workspace.

Please let the uses value for step access the github context or enable sibling composite actions to be called with the same ref as the current composite action some other way.

[mbrancato]

To @oblivioncth's point on the workaround, this is possible but not ideal. From an experience standpoint, I think I would want <org>/<repo>/<path> to reference the current git ref if in the same actions repo.

This is possible with the outer action doing the following step:

    - name: Symlink current Actions repo
      env:
        GH_ACTION_REPO: ${{ github.action_repository }}
        GH_ACTION_REF: ${{ github.action_ref }}
      shell: bash
      run: ln -s /home/runner/work/_actions/$GH_ACTION_REPO/$GH_ACTION_REF/  /home/runner/work/_actions/current

There is a GITHUB_ACTION_REF and GITHUB_ACTION_REPOSITORY env variable, but they seem broken as they are set to empty strings. So don't use those as your env directive will be overwritten with empty strings.

Additional actions can then be called like the following:

    - name: Do something
      uses: ./../../_actions/current/my-action

Where my-action is the path to the other composite action you would like to call.

[oblivioncth]

Definitely agree this still isn't ideal, but its a better workaround then what I described.

Thanks for sharing.

[mbrancato]

I did identify a slightly cleaner way to do the same thing:

    - name: Symlink current Actions repo
      working-directory: ${{ github.action_path }}
      shell: bash
      run: ln -fs $(realpath ../)  /home/runner/work/_actions/current

[ringerc]

It'd be really good to see github improve this by supporting

uses: ${{ github.action_path }}/../other-action

or

uses: ${{ github.action_repo_root }}/other-action

[AndreyNautilus]

To summarize the answer from @mbrancato and some github documentation, here is the code that I used at my work.
If we take the action repo layout as

my-cool-repo/action.yml
my-cool-repo/subfolder1/action.yml
my-cool-repo/subfolder2/action.yml

then the code in subfolder1/action.yml will look like:

- name: Symlink current action repo
  env:
    action_path: ${{ github.action_path }}
  run: ln -fs ${{ env.action_path }}/.. .github/.action_repo.my-cool-repo
  shell: bash

- name: Call the root action
  uses: ./.github/.action_repo.my-cool-repo

- name: Call the sibling action
  uses: ./.github/.action_repo.my-cool-repo/subfolder2

- name: Unlink the action repository
  run: rm -f .github/.action_repo.my-cool-repo
  shell: bash

Of course .github/.action_repo.my-cool-repo can be changed to whatever path in the workspace. And ${{ env.action_path }}/.. must be a path from your action_path to the root of the action repository.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[pespinel]

Any news?

[oblivioncth]

Probably shouldn't have let this closed/changed it to a suggestion, but I just noticed that reusable-workflows already support being called from the same repository using the current commit, so I don't see why composite actions shouldn't be.

[oblivioncth]

Still not as ideal as native support, but I just stumbled upon something pretty dang close: https://github.com/marketplace/actions/dynamic-uses

The example they show is for doings something slightly more complex, but the tl;dr is that essentially with this you can use context variables in the "uses" key when calling a dynamic action!

[birjj]

Just to summarize, and to point out a few details that weren't pointed out:

The basic idea

GitHub Actions doesn't let us use dynamic uses: values. You can't use uses: ${{ github.action_path }}/my-sibling-action, and you can't use uses: my/repo/my-sibling-action@${{ github.action_ref }}- the value in uses: must be static.

This means that the only way to use a sibling action from the same ref as the currently running ref is to 1) put its files in a fixed location in the runner, and 2) point to it using a relative path:

- name: Link to sibling actions in a fixed location
  shell: bash
  run: |
    # find the root path of your sibling actions by referencing the path of the current action on disk
    SIBLINGS_PATH=$(realpath "${ACTION_PATH}/..")
    # and store it somewhere that we know the relative path to
    SYMLINK_PATH='.github/.action-siblings'
    ln -fs "${SIBLINGS_PATH}" "${SYMLINK_PATH}"
  env:
    ACTION_PATH: "${{ github.action_path }}"

- name: Use sibling action
  uses: .github/.action-siblings/my-sibling-action

Problems

This... works? Unfortunately it runs into trouble relatively quickly:

• Checkouts break it unless you're careful
  If you place your relative path within your default working directory (as we do above), any actions/checkout steps will overwrite the symlink. This means that your uses: ... references will no longer work. To fix this, move the path out of the current working directory and reference it as a path relative to ${{ github.workspace }} (GitHub Actions doesn't block path traversal in uses:, which we can abuse):

  - name: Link to sibling actions in a fixed location
    shell: bash
    run: |
      SIBLINGS_PATH=$(realpath "${ACTION_PATH}/../")
      ROOT_DIR=$(realpath "${WORKSPACE_PATH}/..")
      SYMLINK_PATH="${ROOT_DIR}/action-siblings"
      ln -fs "${SIBLINGS_PATH}" "${SYMLINK_PATH}"
    env:
      ACTION_PATH: "${{ github.action_path }}"
      WORKSPACE_PATH: "${{ github.workspace }}"
  
  - name: Use sibling action
    uses: ./../action-siblings/my-sibling-action

• Nested actions break it unless you're careful
  If you have a chain of actions that call eachother, e.g. my-action-a calls my-action-b which calls my-action-c, then you'll be creating your symlink in my-action-a, and then my-action-b will have its ${{ github.action_path }} set to the symlink path. This means that the above code will overwrite the symlink with a symlink to... itself. Be careful to avoid collisions, e.g. by creating a unique symlink for each action:

  - name: Link to sibling actions in a fixed location
    shell: bash
    run: |
      SIBLINGS_PATH=$(realpath "${ACTION_PATH}/../")
      ROOT_DIR=$(realpath "${WORKSPACE_PATH}/..")
      SYMLINK_PATH="${ROOT_DIR}/action-siblings/my-action-a"
      mkdir -p "${ROOT_DIR}/action-siblings"
      ln -fs "${SIBLINGS_PATH}" "${SYMLINK_PATH}"
    env:
      ACTION_PATH: "${{ github.action_path }}"
      WORKSPACE_PATH: "${{ github.workspace }}"
  
  - name: Use sibling action
    uses: ./../action-siblings/my-action-a/my-sibling-action

• Every bloody action you have that uses a sibling action must have a bunch of code wrapped around it
  You have to manually add a step to create the symlink first, and then clean it up after your action has finished. There's no way to share this code across your actions (other than creating an action for it, which seems like a circular problem, or adding an entire templating language on top of your actions), so it's literally repeated across all your actions.

  It's... a mess. All of this could be avoided by GitHub just allowing dynamic uses: paths.