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://github.community/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 😁 )

[Valentinfe]

+1

[aarbanas]

+1

[joelfernandes23]

+1

[abdala762]

+1

[charles2910]

+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. ⭐