Feature request: allow workflow configuration in sub-folders · community · Discussion #18055

I like the suggestion about collapsible folders on the UI.

@MunchyYDL, keen to see if Github will implement/develop this feature.

I'd like to add my support for the folders under .githuib/workflow that would be displayed as collapsable folders in the UI

This is enough for my needs. I have setup Automated Tests in the Workflows, using the Runners. And it's so many suites and tests that being able to organize my test suites would be cool. Because I also have workflows that do Slack notifications and are reused. So a common/ folder would be good for those.

Forcing GitHub to recurse through the entire tree, or even a large slice of a tree whenever it receives any event is almost certainly a non-starter.

what do you think is going to happen if you have a bunch of files like

.github/workflows/foo-service.yml
.github/workflows/bar-service.yml
.github/workflows/baz-service.yml

that all implement use to point to additional actions in subfolders like:

# in .github/workflows/foo-service.yml
uses: ./services/foo-service/ 

# in .github/workflows/bar-service.yml
uses: ./services/bar-service/ 

# in .github/workflows/baz-service.yml
uses: ./services/baz-service/ 

GitHub is going to load all of those actions in the root of .github/workflows and THEN have to ALSO go into those subfolders anyways.

Sound like even more work than just recursing through a folder structure like:

.github
    - workflows
        - foo
            - service.yml
        - bar
            - service.yml
        - baz
            - service.yml

which is not an unreasonable request in this day and age

That isn't how the GitHub Action Runtime works.

When it gets an event, it only needs to enumerate objects in a single folder (on at most two branches -- default and the current one).

For each object, it then decides if the workflow is enabled, and then if the workflow applies.

If it's enabled and it applies, then it dispatches it to a mechanism that will send things to runners which will then digest the uses lines. It's done much later in the pipeline, and it isn't done by enumerating all objects in the repository, it looks for very specific paths ./services/baz-service/ {action.yaml | action.yml }

find .github/ -type file -name *.yml is incredibly fast. There is really no excuse for preventing users from organizing their workflows.

@jeffrey-aguilera Not only do some repos contain yaml files that aren't github workflows, some repos contain valid github workflows as the content of the repo, not as workflows to be run on that repo.

You can do a lot of this by using a services/foo-service/action.yml and then put uses: ./services/foo-service/ into your .github/workflows/foo-service.yml.

My biggest gripe with this is that it doesn't give you any possibility to organize workflows in the UI. I have several dozen workflows, over a hundred, which do exclusively the uses thing with a handful of reusable workflows. It's time-consuming, with the current actions UI, to find the one I'm looking for. Without some structure inside /github/workflows, or an artifficially created one by specifying something like `path: ["sub-dir-1", "sub-dir-2", "sub-dir-3"] for the workflows to be shown in a tree structure, I can't see how reusable actions/workflows can help with this problem.

I'm not sure that works at all, but I know it doesn't work when adding, removing, or renaming workflow files

yes it does not work unfortunately. Wish it did

I've tried using symbolic links and GHA will raise errors when trying to parse workflow files

A good workaround is symbolic links in your root directory .github/workflows folder

Not really. Even if it would work, the workflow links inside .github/workflows would still be presented as soup. You can't easily work with that soup when you have well over a hundred workflows in the same repo.

All I did was paste in the emoji in vscode in front of the name :P it was a little silly:

name: '⚡ ci'
on:
  workflow_call:
    inputs:
      node-version:
        description: Node version
        type: string
        required: true
      working-directory:
        description: Working directory to use
        type: string
        default: './'

jobs:
  test:
    name: Test
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ${{ inputs.working-directory }}
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Use nodejs ${{ inputs.node-version }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ inputs.node-version }}
          registry-url: 'https://npm.pkg.github.com'

      - name: Install with package-lock
        run: npm ci
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NODE_AUTH_TOKEN }}

      - name: Compile typescript
        run: npm run build
      - name: Tests
        run: npm run test

I have since abstracted these workflows into a separate repository and now referencing them like so across several similar projects:

name: ci
on:
  pull_request:
    branches:
      - main
      - release/**

permissions:
  contents: read

jobs:
  ci:
    uses: orgname/repo-name/.github/workflows/ci.yml@main
    secrets: inherit
    with:
      node-version: 18

thanks @zomgbre I guessing there's no way to actually display the emoji directly within the github actions list in a way to help group them?

You can copy the emojis from here: ❤️
https://gist.github.com/rxaviers/7360908

It's gotta be the actual emoji and not the markdown :heart: Hehe, it seems counter-intuitive a bit because you'd think it would render with the colons.

Ah that's amazing, that's where I was going wrong....much appreciated for your help @zomgbre

If anyone willing to use it, I just updated and released hawk, now is "generally available" ✌️

At this point I am convinced they keep this as their morning fun. While sipping hot nice coffee, they scroll and laugh at new people having encountering this problem.

They are like "Huh, you thought it was obvious, but we got you!", sip, sip, sip... hahaha, sip...

@MrAtkinson sadly nothing right now, we have search still as something we are trying to do as a 'paper cut' small fix in this direction. But other than that :( we haven't been able to get to this yet.

Thank you for the positive engagement and I do read the requests coming into this and all these tickets, there are sips but it's mainly 😭 at the rate we are solving them not laughter. (maybe manic laughter eventually if we get near shipping).

Thank you all for the positive engagement still, one day we will get out of the man in a cave with no shelves ❤️

If MS would stop laying off so many of their developers (and replacing them with AI) maybe this would have been shipped by now 🤷🏻‍♂️

@silkfire I could vibe code the feature for this with AI in 20 minutes. That's not the issue lol

I also just did this in a monorepo... could not overstate my disappointment.

That means you will experience happiness 2 times. First is when you were organizing your workflow files. Second will be in abt 7 years when they finally implement this.

Well, that actually is nice suggestion as small plugin.

Well, I did create fast extension for it. and it does work nicely. Whole logic is to name files with underscore as you mentioned.
I have created it for VS Code only at the moment, however will update for JetBrains IDEs and Visual Studio.
I did publish it as extension for easier installation using ext install LimitlessSoft.github-workflows-explorer
Source code can be found here

They are reading. You can see response from GH actions PM a little bit above (here)

We do :)

Sorry this one hasn't come up yet. I appreciate that it's the second most asked for thing by the community (after parallel steps). We are still looking at burning down 'quicker bits' than this , but come the new calendar year (hopefully 🤞 ) we will start working out what we may do here.

Sorry again that this is still sitting.

burn

What bits could be quicker than this? Short of changing a font weight this appears to be a very small feature.

We do :)

Sorry this one hasn't come up yet. I appreciate that it's the second most asked for thing by the community (after parallel steps). We are still looking at burning down 'quicker bits' than this , but come the new calendar year (hopefully 🤞 ) we will start working out what we may do here.

Sorry again that this is still sitting.

Would the team consider putting those quicker bits aside to prioritize the second most asked for thing by the community if I said please?

I'll do one better: I'll buy the entire team beers next time I'm in Microsoft land.

Another way I am using at the moment and playing around with is to create separate repository like this-project-github-actions and there you can create subfolders like ~/do-this within which you will have action.yml (name of file must be like this).
After that, from original repo you can call this exact workflow like uses: YourUserOrOrganization/this-project-github-actions/do-this.
You can't have multiple different actions within same directory (at least I haven't tried finding way how to do it), but at least you can nest them so maybe it can fit your case.

Another way I am using at the moment and playing around with is to create separate repository like this-project-github-actions and there you can create subfolders like ~/do-this within which you will have action.yml (name of file must be like this). After that, from original repo you can call this exact workflow like uses: YourUserOrOrganization/this-project-github-actions/do-this. You can't have multiple different actions within same directory (at least I haven't tried finding way how to do it), but at least you can nest them so maybe it can fit your case.

yes that could be a good way too, I will definitely consider it. thanks.