Does this support sub-path actions?

[stevehipwell]

Does this action currently (it doesn't look like it) or intend to support creating actions at a sub path rather than at the repo root?

There are a large number of widely used actions that follow this pattern.

[jsoref]

I'm pretty sure it does, because github/codeql-action is a repository that uses it:
https://github.com/github/codeql-action/actions/runs/18195117225/job/51799213506

And it has child actions: https://github.com/github/codeql-action?tab=readme-ov-file#actions

[stevehipwell]

@jsoref that appears to be publishing a single "action" that can be referenced at a sub-path which IMHO is significantly different.

[jsoref]

Can you provide an example? I'm not sure I'm familiar with this..

[stevehipwell]

@jsoref it would just involve having multiple actions in a single repo with a different publish lifecycles so when one was published you wouldn't necessarily have to publish them all. I can't say I particularly want this functionality, but the second order effects would be a better pattern for publishing standard actions (e.g. no bundling up the whole repo contents).

[jsoref]

Since what it's doing things to is the contents of a tag, I think the answer is "no".

Personally, while I can understand having a monorepo for development, I think it isn't the right choice for releasing actions -- certainly not in the decoupled manner you're imagining.

Since the size of a working directory for a commit directly impacts the time to download an action for a commit, it would make sense for you to do this.

• See Action takes 5-6 seconds to download github/codeql-action#2542 where github's codeql-action had a 300mb (possibly bigger by the time they got around to fixing things?) disk footprint and was shrunk to 45mb (by deleting gobs of data from their commits) which dramatically improved the start times for workflows.

• As a best practice, what I'm suggesting is correct. See Action takes 5-6 seconds to download github/codeql-action#2542 (comment) and Action takes 5-6 seconds to download github/codeql-action#2542 (comment) which confirms the general point.

Obviously it will depend on how interrelated your actions are, but if they're truly unrelated, then removing everything else is the right thing. -- Note that if you're going to be releasing just a subpath, you might as well move things from the subpath to the root so that instead of someone doing uses: some-long-org/some-long-mega-repo/some-long-action-name@v100.3657.723, they can use uses: some-long-org/some-long-action-name@v2.652.12.

You could do something like:

name: Publish an action
on:
  workflow_dispatch:
    inputs:
      action:
         type: string
         required: true
         description: "Action to release"
      version:
         type: string
         required: true
         description: "Version for action"
      ref:
         type: string
         default: main
         required: false
         description: "Reference in repository to use for action"

jobs:
  publish:
    runs-on: ubuntu-slim
    steps:
    - name: Checkout Destination
      uses: actions/checkout@v5
      with:
        repository: ${{ github.repository_owner }}/${{ inputs.action }}
        ref: ${{ inputs.ref }}
        path: source
        ssh-key: ${{ (inputs.action == 'action-1' && secrets.action_1_ssh_key) || (inputs.action == 'action-2' && secrets.action_2_ssh_key) || '' }}
    - name: Checkout Source
      uses: actions/checkout@v5
      with:
        ref: ${{ inputs.ref }}
        path: source
    - name: Commit and Publish
      env:
        action: ${{ inputs.action }}
        version: ${{ inputs.version }}
        ref: ${{ inputs.ref }}
      run: |
        : Commit and Publish
        (
          cd dest
          # Remove current files
          git ls-files -z | xargs -0 git rm -f
          # Restore workflows
          git checkout HEAD -- .github/workflows || true
        )
        use File::Basename;
        (
          cd source
          git ls-files -z
        ) | perl -e '
          $/="\0";
          my %seen;
          while my $item (<>) {
            chomp $item;
            $item =~ s</.*><>;
            next if defined $seen{$item};
            my $name = basename($item);
            rename ("source/$item", "dest/$name");
            $keys{"$_\0"} = 1;
          };
        '
        cd dest
        git add .
        git commit -m "Release $action ($version) from $ref

        by $GITHUB_ACTOR"
        git tag "$version"
        git push origin "$version"

-- note that this isn't tested, it has only existed in a text editor. But it's conceptually a thing that kinda makes sense. If the code mostly works, most of your changes would be to the Checkout Destination step. The Commit and Publish step assumes that's there's a .github/workflows directory that's responsible for triggering the publish-immutable-actions bit using whatever available either on the default branch of destination or in a child directory of the source action root.

Obviously you shouldn't trust a random person to give advice, but you should be able to play with this and make it work. The perl is just a bit of magic to move only the directories (including hidden directories) from the one repository to the other. I'm sure there's a better way to do it, but it's just a sketch, you're free to use any language...

[stevehipwell]

@jsoref I'm after Docker like semantics primarily with an ignore file (#219) but also a context (this issue). Personally I don't want to have multiple actions in a single repo but there are plenty of examples of this including the CodeQL one you linked to above as well as repos with an action inlined into the code repo. The main thing here for adoption is that it needs to be first-party supported and not just a technical workaround.

[jsoref]

I understand.

I don't think you'll find it. There's no incentive for GitHub to offer it. Trying to add it would require them to add complexity in a place with limited transparency to a thing designed for security. Whereas GitHub really wants people to use district repositories which provides visibility and other properties.