Let’s talk about GitHub Actions 💬 ✨

[samus-aran]

As we wrap up the past year, we want to take a moment to reflect on everything we’ve built and shipped for GitHub Actions together.

When it comes to GitHub Actions, you’ve told us what improvements matter most: faster builds, better caching, more workflow flexibility, and rock-solid reliability. We heard you.

Across the year, we delivered a number of improvements directly shaped by conversations you started.

Our detailed year-in-review blog post outlines each update in full, but below is a brief summary to give a quick recap of the main highlights.

• YAML anchors: reducing duplication in complex workflows:
  one of the most requested features across both the runners and community repositories. Letting you define configuration settings once with an anchor (&) and reference them elsewhere with an alias (*).

• Non-public workflow templates for consistent CI across teams:
  we released non-public workflow templates, a longstanding request from organizations that want consistent, private workflow scaffolding. Non-public workflow templates let organizations set up common templates for their teams directly in their .github repository.

• Deeper reusable workflows for modular, large-scale pipelines:
  we shipped increases to reusable workflow depth (another key request from the community). Reusable workflows let you break your automation into modular, shareable pieces.

• Larger caches for bigger projects and dependency-heavy builds:
  repositories can now exceed the previous 10GB cache limit that was only possible due to our architecture rework, and fulfills a request from the community, particularly among some of our largest users.

• More workflow dispatch inputs for richer automation:
  increased the number of workflow dispatch inputs from 10 to 25, which also came up in our community discussions.

These are just a few. The full blog post includes additional context, further examples of community impact, and so much more. This space is dedicated to hearing your side of the story.

What’s coming in early 2026

This is just the beginning as there is much we want to do to deliver an even better experience with Actions. Here’s what we’re planning for the first quarter of 2026, influenced by some of the top requests from our community

1. Support for timezones in scheduled jobs and updates to schedule reliability
2. Return the run ID from workflow dispatch
3. Adding a switch function for expressions so they have a conditional operator or function
4. UX improvements including faster page load times, better rendering for workflows with over 300 jobs, and a filter for the jobs list

We’re interested in hearing how you plan to use these upcoming capabilities and which ones you believe will make the biggest impact.

Help us shape the 2026 roadmap for GitHub Actions

We’d love to use this space to really understand what you need and what excites you as we think about the 2026 roadmap for GitHub Actions. This is a chance for us to learn from your experiences, hear what’s working, and explore where we can take things next together.

Share your stories

If any of the updates we highlighted have helped you this year, we’d love to hear your stories. If GitHub Actions is key to your work, share what it’s helped you accomplish. If you have done something with Actions you are proud of, share it with us! The team cares deeply about it, and your feedback and appreciation mean a lot to them.

What you still need

If there’s something you’re still hoping for, we’d love to hear what it is and how it would change the way you work or what it would unlock for you. Feel free to share any discussions that reflect your experience or needs.

Hearing directly from you, our users, keeps us connected to what really matters, and we appreciate you being part of the conversation. We know GitHub Actions powers how developers build software, and the best version is the one we’ll build together.

[StephenCleary]

Adding a switch function for expressions so they have a conditional operator or function

I am very excited about this!

[hfhbd]

I am very sad to read about the stalled Immutable Actions Publishing . When writing a JS action, you often need other dependencies so you build a (minified/bundled) dist file. This dist file needs to be checked-in into the repository, which is not a good practice. It is a build artifact/output and should be generated by the CI and uploaded to a package registry or as a release asset only.
With immutable releases, it is still needed to check in the dist file, instead of downloading the dist from the release assets. When do you plan to change the current behavior?

[nebuk89]

Ah, sorry I didn't realise I had posted it in maintainers 🤦 It's been a busy old week :D re-posted below

I want to address 3 things:

The feedback in the blog
The changes to immutable Actions
What comes next.
The feedback: is really solid and I hear it. My plan was to have a good chat and get Andrew's advice, as he has clearly thought a ton about this as well on what we have coming and where he thinks we should be doing more. We can also use this thread to dive in more, I also like the idea of a lockfile, but it's something we haven't dug into as we were focused on (2) which I will come to in a sec.(

If anyone has thoughts on how this would impact Actions DevEx let me know what your thoughts are there.

Immutable Actions roadmap item: this is honestly a story of pain. We had planned to move actions into our registry as immutable objects, but the honest outcome here is that we took down our registry a few times and sunk time in hardening the registry as a result(thus the date changes).

In parallel to this, our sibling team had done the hard work to finally ship immutable releases (something that was off the cards when we started our immutable Actions work). Given this, we made the hard call to 'stop' immutable Actions in the form it was in, and instead we shipped an org setting for enforcing sha pinning .

We could have kept pushing on the registry (we felt like we were maybe there, but things like deadlocks kept coming back and burning time to resolve and impacting customers) and given that 'immutable releases are now there', I didn't want to fall to the sunk cost fallacy. Not an easy choice.

What comes next: We had planned in the first part of next year to move over Actions to immutable releases and add new default settings around this to start pushing folks over to at least solve mutability; but we know this is really just making SHA pinning human-readable not moving this forward a great deal.

How we solve the transitive dependencies, viewing a dependency tree, integrity, and then out of that reproducibility - we need to start work thinking on once we have the basic of immutability in place.

Other aspects of Actions security
To engage broadly on that feel free to jump into https://github.com/orgs/community/discussions/179107 where we have discussions on other parts of this going.

[hfhbd]

Well, there are two directions: a real repository or finally just get rid of the checked-in dist files in the repository. These features are related but different. You can have both by setting up a real repository, or the latter only.

IMHO I only care for the latter and you already have a good immutable "repository": release assets. It is battle proven and used in many workflows, and you can easily push/attach the dist files to a release.

With immutable releases, I would expect when checking out an action, the action downloads the uploaded dist file from the release assets instead of using the local dist file stored in the checked out repository.
There might be the need of adding a new attribute/or value to the yaml config that specifies the name used in the release assets.

runs:
  using: node24,
  main: "dist/actions-setup-version-main.mjs" # old

runs:
    using: node24,
    main: "@releases/actions-setup-version-main.mjs" # new (or use a new attribute)

IMHO this is the only change: if main starts with @release download the release asset from the corresponding release tag and use this dist file. If not, fallback to the current behavior.

You could also upload the action file into the release assets to prevent checking out the whole repository of the used action. In this case, I would expect to always use release assets only so you could drop the @releases prefix: `main: "actions-setup-version-main.mjs"

[jsoref]

The approach I recommend for people is to push dist only releases (well, action, README, dist) removing tests, sources, and workflows. That way when a user pulls in an action, they're only downloading what they need (the github/codeql-action repository used to cost 6s, which was pretty expensive -- they've dramatically improved things by not keeping node_modules in their releases).

[hfhbd]

Another missing key feature is fine grained token support for Packages to generate a temporary access token when using a GitHub app with package scope to not use a PAT for packages during CI: github/roadmap#558 (it is still open but not on the roadmap anymore...)

[nebuk89]

👍 good call out, I will sort out maybe something in the new year as another blog or clear update on what's coming for packages as well.

Thank you for sharing!

[jsoref]

• github.action_repository and github.action_ref are empty in run for composite actions actions/runner#2473
• Improve error reporting for fatal errors like Bad Credentials actions/runner#1813 was added to a board and then fell off
• Improve may not be used more than once within the same scope. to identify the location of the other instance  actions/runner#3121
• Problem matchers do not work on colored output actions/runner#2341
• Confusing error on macOS Second path fragment must not be a drive or UNC name actions/runner#1914

In general, if the org believes in open source, it should take some steps to respond to its tickets. I have more than 25 open pull requests nearly 40 open issues.

• Add missing mandatory rootDirectory argument to uploadArtifact(...) actions/toolkit#2202 (for documentation that was wrong from day 1)
• Fix scala workflow actions/starter-workflows#2710 (not quite a year old, but close)
• Remove excess permissions from pages workflows actions/starter-workflows#2597 (a year old)
• Add warn-on-failure actions/download-artifact#286 (nearly 2 years old)
• Missing download info for message could be more helpful actions/runner#3783

I don't believe you've heard me. Since I've been complaining for years in various forums. But I'd love to talk to an actions PM.

[nebuk89]

We are going to start working through the backlog of the open source repos in the new year. We are going to go depth first, starting with runner and trying to get that one cleared up at least as a start <3

[nebuk89]

And every Actions PM knows how invested you are @jsoref :D <3 let me email you now and we can sort time in the new year to chat along with the PMs on my team

[nebuk89]

Let me know if you didn't get the email @jsoref. Excited to chat!

[jsoref]

I can't find it. I sent an email...

[jsoref]

The ways forks are handled is so many disasters.

• needs/if should prevent errors about nested jobs violating permissions actions/runner#4151 is quite fun. It's clearly a surprise to workflow authors.

[nebuk89]

cc @salilsub this is a new one to me good catch

[jsoref]

Let's talk about the fact that Startup failure isn't a filterable category and isn't included in failure and the fact that this has been ignored for years.

• Filter for failure doesn't include startup failure #181848

[nebuk89]

I was going to say I hadn't seen this issue before, but that's a new one! Thank you for raising. I will check in on why..

[BenRogersWPG]

Would love support for updating the run-name throughout the entire job, similar to the action summary:
https://github.com/orgs/community/discussions/69476

Other recommendations:

• If you run an action, and then run a second action with concurrency on. The second action will queue. But. It freezes any repo-variables when it queues. So if the first action runs and edits some repo variables, the second action, when it finally runs, will use the OLD values of the repo variables in the workflow, which is a major annoyance when running actions.

• On GitHub mobile app, the actions run summary should display. It is just simple markdown, and would be a huge benefit to the mobile app.

• It would be really neat if workflow concurrency was able to hold more than just 1 action in queue per group. I have a concurrency group on all workflows that perform commits, so there aren't merge conflicts, and sometimes 3 workflows can run at the same time, and it will cancel the oldest one. It would be nice to not limit how many items are in a queue (this could be a setting when coding concurrency)

• I would love a way to be able to display a bit of markdown to the top of a action on the website - or even just a way to add a hyperlink to a action's workflow_dispatch input description.

[jsoref]

• freezes ... repo-variables when it queues -- ouch

• On GitHub mobile app ... I reported this as Summary doesn't include step summary #164812 (comment) @iskae said they'd make an internal ticket. Note that I think that the Actions category is distinct from the Mobile category (I believe they're different teams), so, I wouldn't ding them here. (I've found them to be generally much more responsive than the actions team which afaict has been AWOL for years.)

• ...concurrency group

  • Using concurrency in workflows shouldn't cancel previously pending workflows #41518 (comment)
  • Support more than one waiting job in a concurrency group actions/runner#1523 Unable to queue more than a single run in a concurrency group actions/runner#2227 -- the "actions/runner" team claims it's out of their hands.
  • Concurrency Cancel Pending #5435 was a previous response (no interest in implementing) ... there's a whole set referenced
  • Feature request: concurrency to queue all jobs waiting on a group #12835 looks frustrating

  ... indeed, this area sucks.
  ... my favorite complaint in this area is Can we suppress 'Run cancelled' notifications? #13015 which really should be fixed if nothing else will be.

• markdown ... on ... website -- can you provide a picture w/ an annotation showing where you'd want something? We have the action summary (minus mobile). For my tooling, I often include links to log items (and even pinned versions of action summaries) to work around some things like this, but I'd love to have a better sense of what you're tripping on. (I don't use workflow_dispatch much, so I haven't really thought much about how inputs work. I'd probably just have my tooling include a section in the step summary either with the info, or with a link.)

[nebuk89]

Renaming and concurrency are things I think we just need to get done in the next 6 months now 👍
Mobile app is cool feedback, I will grab the mobile PM and discuss this one :D

The display markdown is interesting.. it's something we were discussing the other day as an idea and it's cool to see it raised as well.

Thank you for sharing <3

[nebuk89]

@jsoref run cancelled notifications - yep, we just need to do, agree.

[candyho]

👋 PM from GitHub Mobile here - we have a ticket tracking support for action step summaries in the mobile apps. I agree this would be really useful, and it’s something we’re hoping to prioritize in the near future.

[jsoref]

• Thanks @candyho -- I'm a fairly active filer in your category. And, in general your team has been much more responsive than some of the other categories. But, that specific item really needs to be fixed sooner rather than later. (I do appreciate it's a much bigger task than a lot of the things I file.) I'm looking forward to kicking the tires. I'm happy to be an alpha tester for it.

[jsoref]

Let's talk about how it's impossible for a normal human to decide how to open a discussion in this category (🚢 Actions).

Let's compare 📱 Mobile with 🚢 Actions:

🆕 📱 Mobile

Explore our GitHub Mobile sign in & troubleshooting guide for comprehensive guidance!
💡 Quick Tip: For general development questions or detailed code issues, try Chat with Copilot first, it might have the answer you need before posting here.
🛠️ Stay Updated: To ensure you’re always on the latest available version of GitHub Mobile, enable auto updates in the Google Play Store or App Store..

Select Topic Area

What would you like to discuss about GitHub Mobile? Choose your topic area.

• Question
• Product Feedback
• Bug
• General

Feature Area

Which GitHub Mobile feature or product area is your discussion related to?

• General
• Android
• iOS

Provide a detailed description of your discussion (e.g., What issue are you facing? What feedback do you have? What question do you need answered?). Please include logs wherever possible.

There are two drop downs:

• A topic area, which a normal user could reasonably select from, or failing that, they can select "General". This is fine ✅ .
• A feature area, the default is "General", and if a user knows they care about Android or iOS, they can reasonably select one. This is great ✅.

There's also a placeholder for the main body, there's nothing wrong here ✅.

---

🆕🚢 Actions

🚀 Welcome to the Actions Category!🚀
Automate, customize, and execute your software development workflows right in your repository with GitHub Actions!
Why are you here?

• Have a Question? Maybe you're stuck on workflow syntax, curious about best practices, or want to know how to use a specific GitHub Actions feature. Select "Question" to get help from the community!
• Product Feedback? Do you have ideas to improve GitHub Actions, or want to share what works (or doesn't) for you? Select "Product Feedback" to help shape the future of GitHub Actions.
• Found a Bug? If something isn't working as expected, let us know by selecting "Bug" so we can investigate and improve the platform.After choosing your reason, pick the topic or product area that best matches your discussion.
  Quick links: Actions Documentation, Workflow Syntax Guide, Example Workflows, and Security Best Practices
  Recent News:
• Latest Breaking Changes

Why are you starting this discussion?

Tell us your goal! Are you asking a question, giving feedback, reporting a bug, or sharing something cool?

• Question
• Product Feedback
• Bug

What GitHub Actions topic or product is this about?

Choose the single topic or product area most relevant to your discussion. Only one can be selected here.

If your post covers additional themes or topics, don't worry! Our team and automation will do our best to add extra labels based on the content of your discussion details.
This helps us get you the best answers and feedback!

• ARC (Actions Runner Controller)
• Actions Runner Image
• Actions Runner
• Actions Checkout
• Actions Cache
• Workflow Deployment
• Workflow Configuration
• Schedule & Cron Jobs
• Metrics & Insights
• Misc

Discussion Details

Share your question, feedback, or story! Include links, code, or screenshots for more context. Tip: Reference the docs https://docs.github.com/en/actions or relevant changelogs for details.

• there's way more boilerplate here, but it doesn't actually add value. For a dropdown, humans who are using a browser already understand they can only select one item. Otherwise it'd be a checklist. Frankly, the prose for this point is insulting 😞 . The mobile team certainly didn't feel a need to do this.
• topic area: unlike Mobile, there's no General. That's a choice 😦.
• product area: There are more categories than for Mobile. Great, but while there was a lot of prose earlier, this is where prose is actually needed for humans not paid by GitHub to work on the Actions product. And there isn't any 😭.

  • What's an ARC? Is it some open source thing? is it some closed source thing? Who knows. https://docs.github.com/en/actions/concepts/runners/support-for-arc indicates it's some adopted thing, but it probably isn't what's used by GitHub, so it probably isn't what normal people care about. Putting this item as the first item in the list is stupid. It's going to attract lots of lousy reports. You can see that Accessibility suffers from this because they are the first category so they have:

    🛑 Please Note: This category is exclusively for discussions about the accessibility of GitHub and its products, focusing on access for people with disabilities. Unrelated conversations will be removed. Thank you for your understanding and cooperation.

    by contrast, the Mobile team put General first in the list. The team can change the category later.

  • What's an Actions Runner Image? Does it include only github supported images or also github partner images? Who knows.

  • Actions Checkout -- Ok, this one I can guess, and hopefully everyone else can too

  • Actions Cache -- Ok, this one I can guess, and hopefully everyone else can too

  • Workflow Deployment -- I have no idea what this means

    • It could be Actions Starter Workflows as noted below, but it probably isn't
    • It could be reusable workflows, but it probably isn't

  • Workflow Configuration -- I'm actually not sure what this is for.

    • Is it where we were supposed to complain about concurrency being a disaster, or about if/needs being a disaster? needs/if should prevent errors about nested jobs violating permissions actions/runner#4151 who knows.

  • Schedule & Cron Jobs -- I'm not sure the difference between Schedule and Cron Jobs. If there's a difference, there should be prose. If there isn't a difference, there shouldn't be two items, just one (presumably Schedule) and prose to explain it's the same.

  • Metrics & Insights -- I'm not really sure about these either.

    • My guess is that Metrics would include https://github.com/check-spelling-sandbox/check-spelling/actions/metrics/usage
    • I guess it would also include https://github.com/check-spelling-sandbox/check-spelling/actions/metrics/performance
    • does it include https://github.com/organizations/check-spelling-sandbox/settings/actions/hosted-runners? Who knows
    • Does it include anything else? I have absolutely no idea.
    • What are Insights? Or how do they differ from Metrics? I have no idea. If they're the same, and if they really are only Insights>*Metrics, then the item could be reworded to hint that it's Insights: * Metrics

  • Misc - Unlike General used by Mobile, this is probably the catch all.

    • Why is it abbreviated from Miscellaneous when ARC (Actions Runner Controller) is almost certainly longer
    • Why isn't it just General like Mobile? I can't think of a good reason.
    • Is anyone supposed to be able to search by this thing? `coverage report` broken on Windows target, no errors on Ubuntu target #42681 shows up in https://github.com/orgs/community/discussions/categories/actions?discussions_q=is%3Aopen+category%3AActions+%22Misc%22&page=13 because it has the word misc somewhere, but it's probably not misc. So, in addition to everything else, this entire item fails SEO miserably.

  • Actions Starter Workflows -- this one isn't on the list, but, why not? There are ~200 open issues, so clearly no one's paying attention to that area.

[samus-aran]

Hey @jsoref, I can't answer specifically about the Actions roadmap but I can assist on the structure of the Actions discussion category.

---

So, you're looking for a "general" label. Sure, I can understand that "Misc" isn't explanatory enough. We'll swap that. We can also keep it the default selection (like we did with Misc).

Frankly, the prose for this point is insulting 😞

Oft.

Only one can be selected here.

If your post covers additional themes or topics, don't worry! Our team and automation will do our best to add extra labels based on the content of your discussion details.

The single select dropdown was a deliberate choice on our end, primarily to keep the form shorter compared to check-boxes. We would've loved a multi-select dropdown but alas discussion templates don't support that. Considering that we added automations that reviews the discussion body and adds additional labels based on key words.

Now, with that, we can certainly explore and test a few approaches to see what works best.

there's way more boilerplate here, but it doesn't actually add value.

Reading your feedback you specifically naming the dropdowns and not pre-text e.g

Why are you here?

• Have a Question? Maybe you're stuck on workflow syntax, curious about best practices, or want to know how to use a specific GitHub Actions feature. Select "Question" to get help from the community!
• Product Feedback? Do you have ideas to improve GitHub Actions, or want to share what works (or doesn't) for you? Select "Product Feedback" to help shape the future of GitHub Actions.
• Found a Bug? If something isn't working as expected, let us know by selecting "Bug" so we can investigate and improve the platform.
  After choosing your reason, pick the topic or product area that best matches your discussion.

Quick links: Actions Documentation, Workflow Syntax Guide, Example Workflows, and Security Best Practices

Recent News:

Latest Breaking Changes

☝️ I could imagine that the Have a Question etc up to Quick links could be redundant. I'm up for suggestions around improving that or removing it completely. We do have to consider that majority of our community users are fairly new to GitHub when making changes.

product area: There are more categories than for Mobile. Great, but while there was a lot of prose earlier, this is where prose is actually needed for humans not paid by GitHub to work on the Actions product.

Fair call out. Most of these naming conventions was from the migration of discussions from the other Actions repos detailed here:

To make things even easier, we’ve introduced new labels and discussion templates to help categorize topics within the Actions category more effectively. Whether you’re submitting ideas, feature requests, or general feedback, these tools will make your contributions easier to track and respond to. Check them out here:

• ARC (Actions Runner Controller) - Discussions migrated from the public /actions-runner-controller repository. Use this label for topics related to the Actions Runner Controller project.
• Actions Runner Images- Discussions migrated from the public /runner-images repository. Use this label for topics regarding GitHub-hosted runner images and their management.
• Actions Runners - Discussions migrated from the public /runner repository. Use this label for topics related to the GitHub Actions runner software and its functionality.
• Actions Checkout - Discussions migrated from the public /checkout repository. Use this label for topics concerning the actions/checkout GitHub Action and related issues.
• Actions Cache - Discussions migrated from the public /cache repository. Use this label for topics about the actions/cache GitHub Action, caching strategies, and related questions.

As for label explanations we can certainly add in a link to their descriptions from the discussion template so folks know what they mean.

Actions Starter Workflows -- this one isn't on the list, but, why not? There are ~200 open issues, so clearly no one's paying attention to that area.

After Spot-checking a number of these issues, looks like a fair chunk of them are spam or low-quality reports. So I believe the "general" label would be sufficient to capture these.

Thanks for taking the time to share this feedback. We appreciate you calling it out.

[jsoref]

• I left a reply in 👋 Welcome to the Actions Community from OS Actions repos! #160762 (comment)

Having to read multiple posts is unlikely to work. The first one is pretty close to TL;DR, adding in the second one is definitely collectively TL;DR. I'd encourage you to consider your audience: frustrated new-ish GitHub users struggling to do something. They've somehow managed to get to:

1. https://github.com/orgs/community/discussions/
2. https://github.com/orgs/community/discussions/categories/actions
3. They now need to figure out what to do. Their patience is running thin. Perhaps they already made it through the https://support.github.com maze only to be told to go to 1.
4. What's the step here? Ideally, it's read no more than one pinned post (preferably zero)
5. Maybe they will try to search, but this is what they see:
   
   Note that while you may imagine labels as being limited to the ones you care about, when users view the list, they're going to see all of them. I'm really not sure why people think that unifying the forums is useful. It makes the search worse. And discussions do support transferring across organizations (I've used the feature - although mostly for testing because I was pretty sure the documentation was wrong).
6. Then they try to create a post
7. Maybe they click latest changes
   
   
   That's unlikely, but if so, they're probably looking for the word "breaking" not "improvement" (I checked, there doesn't seem to be a category for that, just deprecated).

Here's a real flow:
I'm a user and I create a pull request and I get a comment from a spell checking workflow. But the branch I pushed to doesn't have such a workflow. The branch I'm trying to merge into doesn't have such a workflow either. And when I find the workflow job run that triggered the complaint (in my case, I'm lucky, the comment included the link, but most workflow/actions authors don't do that), and click the link to the workflow file, I get an error saying it doesn't exist.

What do I do?

1. Towards a secure by default GitHub Actions #179107
2. Maybe I search
   https://github.com/orgs/community/discussions/categories/actions?discussions_q=is%3Aopen+category%3AActions+pull+request+target
3. There are pages and pages of results. I'm not going to read each hit. They're mostly lousy.
4. I'm not going to find that they're covered by a "towards a more secure GitHub" discussion. Posts should have a single topic that's descriptive and has reasonable SEO.

---

Note that I think I've already filed a report somewhere about the workflow link not working. But, this morning I can't find it. I'm a power user and I can't find a complaint I know I made. It's possible I sent a support ticket, but I'm pretty sure I didn't. And if I did, I'm pretty sure it would have told me to come here.

• If I go to /issues, I end up at issues assigned to me.
  And I don't think I can change that.
  Sure, an engineer might care most about their new work, but most GitHub users aren't really developers, they're users and they care about the problems they've reported.
• I use the unified search and try issues and discussions and can't find it

Moderator's Edit: Set width of images for easier reading.
Poster's Edit: Post made with GitHub Mobile Beta for Android; added line wrap -- it's hard to compose anything in mobile.

[jsoref]

Reading your feedback you specifically naming the dropdowns and not pre-text e.g

I think the current pretext is wasteful. Having a link to the descriptions of the choices (labels, apparently, but only once they're fixed to be useful) would be much more valuable.

I'm really not sure why "ARC" was so important -- that so many people knew it over "Actions Runner Controller" -- Personally, I'd probably rename it to K8s Actions Runner Controller and sort it lower in the list. The vast majority of people coming here won't be asking about it, so giving it top or near top billing isn't helping anyone (not the people who actually maintain it since they'll get misfiled posts they need to refile or drown in; nor people who actually want something since it probably won't be this; nor people who do want it, since searching in it will find lots of misfiled items).

[jsoref]

• @samus-aran I just opened Filter labels does not seem to work #183143 -- until this is fixed, you should not use that feature. It's horribly broken, and the fact that you provided it as a link without testing feels insulting.

[jsoref]

• A reminder that announcing things asking for feedback, and then ignoring the feedback, GitHub Artifact Attestations are generally available! #129761 (comment), leaving bad information for people to read kinda sucks for everyone.

[jenseng]

I would love to see more engagement and collaboration with open source developers, since that (presumably) is what GitHub is all about. The various actions/* repos have issues and pull requests enabled, but as of late have all added this disappointing note to their READMEs:

Thank you for your interest in this GitHub repo, however, right now we are not taking contributions.

We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time.

I know first hand that running an open source project is challenging, and triaging issues and pull requests can be a big time sink. But surely there's a better middle ground?

Taking actions/runner as an example, there are many longstanding bugs/limitations that have simple PRs¹ to address them, but they haven't even had the slightest acknowledgement from maintainers. That doesn't really "help [y]our customers be successful while making developers' lives easier". I would love to make even more substantial contributions (e.g. support expressions in uses, so that hacks like dynamic-uses aren't needed), but why bother if there's no chance it will ever get looked at? 😞

Footnotes

1. There are many more, but here are some I'm familiar with:
   2430: Fix color code detection
   2710: Fix local composite action context data
   3143: Reduce CPU usage of safe_sleep.sh
   3406: Fix exit code handling
   4053: Add JOB_ env vars ↩

[nebuk89]

Yeah this is very fair @jenseng . I added this comment in pretty much as I was feeling bad that we were not being good open-source custodians and I didn't want even more folks wasting times on PRs that we were not reviewing.

We are going to be pivoting back into our open source repos in the new year :) we are just trying to work out 'where to start' right now!

[nebuk89]

My gut is to start in runner and toolkit, but if others have thoughts of which backlog we should plow through first - let us know

[jnewland]

The runner-images repo has mentioned this in the readme for two years:

We are in the process of preparing macOS CI to accept contributions

Is this still planned? I frequently have to shift workloads away from hosted runners to a self-hosted runner to access a beta Xcode or MacOS version.

[nebuk89]

We are re-working how we think about our image releases and are trying to decide if we move to having some Xcode named images.
A part on this journey is that right now each image build is 'unique', what we want to (ideally) do first is have the ability to build a base (of all the other MacOS tools) and then take that base and build '2 images from it'.

This would mean we could have a lot more of these images. Actively working out what we do here as we have similar issues with VS on Windows and we know we need to do better

[jnewland]

So that's a no on the "enabling contributions" front then, eh? Do y'all have a SLO for major/patch releases in mind?

The worst part of the experience here with MacOS runners being closed source is that every time I need an update to hosted runners I'm helpless with no policy to inform my expectations. I'd rather spend the time I spend updating my Mac Mini updating an open source image instead, but at least it's something I can plan for and control for the time being.

[Kichura]

I currently am awaiting for a 2nd linux distribution image to be included as a fallback operating system in the event that Ubuntu itself is failing to function properly as requested in the partner-runner-images repository.

but tl;dr: GitHub Codespaces has Alpine Linux available as a fallback operating system when Ubuntu fails to start up properly but not GH actions itself.

[nebuk89]

Would you be up for something like Fedora?

[Kichura]

Would you be up for something like Fedora?

As included in my initial comment in that issue: "Fedora was originally talked about by the general public but that one gets updated so frequently that it has stability concerns which is why i changed the main subject to say AlmaLinux instead."

But to summarize, I do not think that is a good idea in terms of a 2nd distribution; unless you have ideas on how to make it workable in workflows where it won't suddenly cause problems then LMK.

[Kichura]

Update: I think Alpine Linux is a better option now that i have seen ubuntu-slim in this repository. @nebuk89

[wd-hopkins]

Asking for workflows in sub folders once again https://github.com/orgs/community/discussions/18055

In my org we have many monorepos with many tens of services in, each with multiple workflows that all live in a flat directory structure. This feels very messy. Finding a particular workflow in the actions tab takes clicking 'Show more workflows' multiple times and scrolling. We've had to work around this by combining multiple workflows into one, but we sacrifice being able to trigger them individually without a custom solution. It might not sound like much but is a huge pain. Some way to group related workflows into folders that are traversable in the actions tab would be a huge QOL for us.

[jsoref]

Personally, I'd work around this by creating a page in the repository that links to the various items. The links are predictable and formulaic.

I deal w/ repositories that have dozens of workflows (because I visit lots of other people's repositories, even some github repositories are pretty unbearable).

---

What I'd want today would be a type to search box at the top:

https://github.com/github/codeql-action/actions
Today:

Simplest fix:

This widget already exists and is used for Required checks in Rulesets.

[jsoref]

• The roadmap has a tangentially related item Support over 300 jobs & filtering in the Actions UI github/roadmap#1190 -- that's for jobs within a workflow as opposed to workflows. I wouldn't expect them to do anything here until that one's delivered.

[nebuk89]

This is an ask thats in a few different forms and we totally hear it.
The precursor work is we actually want to re-work how Workflow Scope works in Q3, moving some of this into a new set of rules (internally we are calling that 'Workflow Execution Protections'). Workflow execution protections will limit the scope of workflow file execution based on input parameters and an administrator-defined scenario. Moving forward, what is reachable can be determined by what is runnable, as defined by administrators.

For us this gives us a new foundation that will then make it far easier to re-do how we handle paths that workflows (and more) can be resolved via.

We should ship Execution protections in Q3, unblocking us to start here in Q4 (assuming this is a top one we want to tackle.. I think it will be!)

[JaKXz]

actions/runner#2380

and actions/runner#3792 (comment)

[nebuk89]

actions/runner#3792 (comment)

[JaKXz]

I think 2380 is still open? Or can you confirm that is fixed @nebuk89?

[JaKXz]

actions/runner#449

[nebuk89]

Yep this was a bad that we re-introduced this. We have work in progress to level up so this won't be introduced again

[jsoref]

Connecting a number of things, there's a desire to be able to step through actions, e.g.:

• Unable to see tmate.io link/connection string mxschmitt/action-tmate#1 (comment)

I can certainly work around such a thing myself by adding steps that look for a while and sleep until it's present (I've done such things all over), but it's clearly something people like to be able to do -- it's a basic function of a debugger (pause / step / continue / break).

There are a bunch of shell implementations

• https://github.com/marketplace/actions/debugging-with-tmate
• https://github.com/lawrencegripper/actions-term-on-fail (fanicer, but doesn't seem to be on the marketplace yet)

[hfhbd]

Another feature I really miss: (Unit) Test result visualization

There is no GitHub built-in feature for uploading (unit) test results, to see the results live during job execution, the history (for flaky tests), and only failed tests etc. GitLab has this feature: https://docs.gitlab.com/ci/testing/unit_test_reports/

Yes, you can use the job summary, but without a (searchable/filterable) history. Also, you can only see the history at the end of the job, while ideally GitHub could show the jobs during execution (via outputting a specific line in the logs similar to the existing output).

Ideally, you can also create an issue/test cases (like in Jira) from a failing test.

[jsoref]

It'd certainly be nice to have a way to do this.

For check-spelling, I have:
https://github.com/check-spelling-sandbox/check-spelling/actions/runs/20982403600#summary-60309998706

... the artifact includes pretty(ish) html.

If I cared more, I'd publish the results using github-pages (which I know is possible, as I have a repository where I host my documentation).

I suppose, if I were doing it a lot, I'd wrap that into an action.
Technically, since I'd probably be publishing to a distinct repository and letting that use an action to publish to pages, I could probably make it update as it goes while my workflow is running. But, it's a lot of work, so I haven't looked into doing it.

[jsoref]

I ended up implementing this... It's in: https://github.com/check-spelling-sandbox/check-spelling/actions/runs/21040487174#summary-60500622548

Publishing Coverage Report (if the link isn't ready, check check-spelling-sandbox/check-spelling-coverage actions for status)

At some point, I'll wrap it into an action since I don't need it in general. It works "well enough for me" and it means I no longer have to click artifact links + expand them and that my results accumulate instead of expiring (and if I wanted to, I could add a workflow to the pages repository to do automatic garbage collection).

[jsoref]

There's a prestep which is really interesting, but once things start, that output isn't available from the ui:

Requested labels: ubuntu-latest
Job defined at: check-spelling-sandbox/check-spelling-coverage/.github/workflows/pages.yml@refs/heads/main
Waiting for a runner to pick up this job...
Evaluating build.if
Evaluating: success()
Result: true
Job is waiting for a hosted runner to come online.
Job is about to start running on the hosted runner: GitHub Actions 1000044131

(from https://github.com/check-spelling-sandbox/check-spelling-coverage/actions/runs/21034109886/job/60477391152)

(I think that info is somewhere in the download logs)

[jsoref]

Run label is wrong for local actions:
https://github.com/PowerDNS/pdns/actions/runs/21035311499/job/60481500040#check-step-17

Run /./.github/actions/normalize-branch-name

That line should correspond to:
https://github.com/PowerDNS/pdns/actions/runs/21035311499/workflow#L201

 - uses: ./.github/actions/normalize-branch-name

But the log has a spurious / disconcerting leading /.

[alexaka1]

Required status checks enhancement

Touches on path filtering, and minutes billing

Currently the docs draw attention to a crucial limitation, namely that required status checks skipped by path filters are not reported as skipped. This can be worked around by running a small job that does the filtering and that job then causes the required status check to be skipped - which can be considered as a success by GitHub.

However this means that CI minutes have to be burned to do this. Even if the workflow takes 1 second to do the filtering, I get billed for a full minute of CI time, which adds up fast for larger teams or more frequent commits/PRs. Which takes me to my next point.

Sub-minute actions billing

I won't try to appeal to the business side of it, we all know why it is how it is. However, since GitHub itself is able to report actions usage with 1 second precision, it would also make sense and would be very beneficial for users to be billed for CI seconds rather than minutes. I am fine with rounding up seconds, so every started second ie. 100ms would count as 1s. This is less user friendly when you do this with minutes, as 1 second of CI time gets billed at a 60x rate. Almost 2 orders of magnitude more.

GitHub clearly has the capability to track actions usage with the temporal precision of 1 second, because many UI elements reflect this, for example:

By doing this, it would significantly reduce the cost of working around GitHub's limitations, and I would be able to justify paying for it. I would like to really emphasise the path filtering limitation is directly forcing us to burn CI minutes to save costs. So we are forced to use more of GHA. If the pricing for this is unreasonable - rounding up minutes, adding a bridge toll to self-hosted runners - then this becomes predatory and a basic conflict of interest between GitHub and the users, since GitHub is now disincentivized to fix it, as this causes them to charge more overall.

Better control plane logic

Dynamic matrix configuration

Having dependent matrix jobs and those jobs having dynamic matrix configurations is currently very finicky. For example, you cannot skip individual matrix jobs, as a result of a previous matrix job.

Imagine the following. You have a monorepo with 5 packages. Your workflow is start a matrix job for each package, and check if a new version needs to be deployed. Return with some value. Then start another matrix job for each, but skip the job depending on if a package needs to be deployed or not. This is currently not possible, because if you put the condition on the job itself, that gets evaluated before the matrix results are available. So you either skip all matrix jobs, or none of them. A workaround would be to then inside the job, add a condition to each step and skip them as needed. However this is very clunky, not maintainable etc. This should be improved.

Required matrix job status checks

Requiring matrix job status checks runs into the same problems as discussed above, with the addition that matrix jobs are inherently unstable. When skipped they report a different name. When successful they report their real name. So if you have a job like the following

test:
  if: >-
    (github.event_name == 'workflow_dispatch' ||
      needs.path-filter.outputs.code == 'true')
    && !cancelled()
  needs: path-filter
  strategy:
    matrix:
      platform:
        - amd64
        - arm64

If the job is skipped, a single job will report skipped named test, but if the condition is true, then two jobs will report success test (amd64) and test (arm64). Which one do you require as a status check? Aha, got you. Neither, you have to do another job after this.

success:
  timeout-minutes: 1
  if: ${{ always() }}
  needs: test
  runs-on: ubuntu-latest
  steps:
    - name: Fail if test job failed
      if: ${{ needs.test.result == 'failure' }}
      run: exit 1
    - name: Fail if test job was cancelled
      if: ${{ needs.test.result == 'cancelled' }}
      run: exit 1
    - name: Success
      run: echo "Success"

And as you can see, I have to burn a full minute of CI for a f***ing exit 1, even if the full test job was skipped for any reason because otherwise I can't have a required status check for this workflow that is the same name regardless of what happens.

Clearer inputs for triggers that don't support them

You can add a bunch of inputs to a workflow_dispatch trigger, you can even add default values. However, if your workflow also supports other triggers, such as push then those inputs need to be handled for a variety of cases. I don't really know how this should be solved, but it would probably be nice to have the option to declare the same inputs on other triggers too, but only set up default values. So inside the workflow I don't have to write 17 inputs.xyz || 'some-value' because i have to do this every single time I access the input. And because of other GitHub limitations I can't make this very easy without burning CI minutes. Like I can't just set this at the top level env block, because that context is not available for example in evaluating the environment in a job definition. Another clear GHA limitation.

Proper ternary expressions

GitHub provides a way to create conditional logic in expressions using binary logical operators (&& and ||). This pattern can be used to achieve similar functionality to the ternary operator (?:) found in many programming languages, while actually using only binary operators.

Frankly this is just embarrassing for a 5T dollar company. (You might say it's unfair to compare GitHub to Microsoft. But Microsoft makes sure to remind me they are the boss around here.)

Self-trigger workflows

Currently workflows cannot trigger each other using the default token. So for example one workflow tags a release and pushes the tag. Another workflow gets triggered by the tag push and deploys the release. This does not work currently, the workaround is using a different token to push the tag, ie. a GitHub App. Which leads to...

OIDC support for GitHub apps

Secretless auth is the hot thing these days, so it is very disappointing that GitHub apps only work via secrets. This makes it very clunky to manage, because you almost always have to put them as a repo secret, which means all pipelines can access it. Because putting into environments means you'd have to copy them multiple times. I would really love just get a GitHub App token via OIDC like you can with Azure, AWS etc. This would make things so much easier.

honorable mentions

• iirc many built in add-on jobs like secret scanning, or dependency submission etc. do not support private registries, and the way to solve this is to make them run of self hosted runners, which are setup with access to said registries. So this should be addressed before self-hosted runners are tolled.

my proposed compromise

Now, charging for the control plane usage... I understand running that infra is not free. I can accept a surcharge for using self-hosted runners, however please put a limit on it, like usage above 1-2 minutes gets surcharged, under it it's free. Because of the above mentioned limitations, I am forced to use CI minutes. I don't want to. Trust me, I spend countless hours trying not to and use the native platform, but I just cannot. So I have to declare these mini-jobs that evaluate conditions for me that GitHub is not able to handle. These jobs take less than 20s to run so running them on even the smallest runner on offer, would cost a not insignificant amount of money. Therefore it is actually a valid trade-off to run these on self-hosted runners. For example:

Job	Workflow	Failure rate	Avg run time	Avg queue time	Runner type	Runner labels	Job runs
Determine if workflow should run	.github/workflows/test.yml	0.00	12664ms	13073ms	self-hosted	self-hosted	232

To me there has always been this gentleman's agreement with GitHub: that they don't fix the platform's shortcomings, but I don't have to pay for the workarounds as longs as I solve them with self-hosted runners. This is just one of the jobs in one repo from the month of January and it will go on to take up 10% of the free minutes of a GitHub Team subscription by the end of the month. We have about 10 of these jobs, so before any expensive CI job even starts in this repo, we have already burned through the subscription included minutes every month. This feels more like protection racketeering than a true free offering.

Lots of accidents happen in this neighbourhood. Wouldn’t want you to run into problems, would we?

Of course if we didn't do any of this, we would just run CI all the time, which would be even more money spent. GitHub of course would be very happy if this was the case, I'm sure.

[alexaka1]

I forgot to add this, but there is also a fun bug with required status checks and adding extra types to the pull request trigger. For example you can add triggers to run CI when a PR is changed from draft to ready for review. If CI was skipped for draft PR, it is considered successful for the required checks. If you click ready for review, there is a 2 second interval where you can click merge because it still sees the skipped runs and accepts them for the required status checks. But if you wait it triggers the new run and now it blocks the PR from merging until they pass. This was fun to discover. Totally worth the .2 cent surcharge.

[chris-burgin]

We desperately need a better version of the setting "Require status checks to pass before merging".

Our organization requires that all running pipelines must succeed before allowing developers to merge. The current functionality makes this impossible without a third party library like https://github.com/poseidon/wait-for-status-checks. We really need a single check-box that says "All running checks must pass before allowing merge". This should apply to both pipelines and merge queues.

The problem with the current "Require status checks...." are three fold:

1. It matches jobs against their names, which can change. This is impossible to maintain at any sort of scale. Having to have an admin modify a setting every time a developer renames, adds, or removes, is not practical.
2. It requires the specified jobs to run and pass even if the jobs is skipped or not present. It is very common for organizations to conditionally run jobs based on file changes, for example.
3. The interplay between merge queues and pull requests make this impossible. For this to work correctly they would need to share the exact same jobs.

These limitations make the current functionality completely non-operation.

In terms of competitors boths Gitlab and Codeberg have a simple "Pipelines must succeed" checkbox to enable this functionality. You can also see the demand for a better solution based on the usage of tools like https://github.com/marketplace/actions/alls-green and https://github.com/poseidon/wait-for-status-checks.

[chris-burgin]

We need the ability to not run workflows when the PR is in a draft state. Currently there is no combination of filters that would allow that. It's almost as if we need negative filters. An !draft if you will.

It is common for developers to open PRs in a draft state very early on before they are ready for review. Allowing actions to run in this state eats up a lot of resources. It would be helpful to specify workflows that only run when the PR is active.

[jenseng]

this is possible with a job conditional like

if: (!github.event.pull_request.draft)

[hfhbd]

macOS runners on GHE.com. It is currently not supported, but there is also no roadmap item to follow.

[nebuk89]

Ah it's coming, I will get the roadmap sorted

[salilsub]

Hi all, just wanted to share an update from the Actions team.

We've had a few new items released:

• Right before the holidays we released UI loading improvements and job filtering.
• Earlier today we announced a number of updates with the theme of "improving the workflow writing experience". This includes our new case function which is adds conditionals for expressions.

We also have a bunch of open items in progress

• Return the run ID from workflow dispatch: We're getting very close on this one, it's already been shipped internally, we're finalizing the the last pieces for the rollout (the HTTP response will be changing so we don't want to break users who are expecting a particular response).
• Parallel steps: This is the most highly requested feature we have and we have a proposed solution which we have been soliciting feedback on. Based on the feedback we've gotten, we're mapping out this work so we can deliver by the middle of the year.
• Better separation of logs in composite actions: This is another issue a lot of people have brought up. We published a proposed solution and we're starting implementation.

This list isn't exhaustive, there are many other things the team is either investigating or actively developing that we aren't ready to share yet. We'll have more updates as we make more progress. In the meantime, we have two asks:

1. Please continue to share feedback in the discussion issues. Providing real world scenarios helps us understand nuances in the problems and the tradeoffs we can make. Upvoting the top comment in discussion issues also helps us understand impact.
2. You may notice me or other Hubbers on the Actions team posting proposed solutions in discussions for feature requests. Please respond to those, even if it's just an upvote. We're genuinely seeking feedback in those cases and understanding if our proposal will work (or not work) is really helpful to make sure we are spending our time building things that actually help you.

Thanks!

[alexaka1]

Is the discussion considered closed, or should we keep sharing feedback here?

[jsoref]

They've been quite inconsistent about things. Often when they make a release and a blog post they create a discussion about their new announcement. But they didn't this time.

[jsoref]

• I posted `case()` function's requirement for pure booleans instead of coercible booleans is incredibly frustrating #185992

[LeonardoReyC]

I suppose someone has already said this, but many actions carried out on a self-hosted runner are for learning purposes, and I don't think it's a good idea to change the current paradigm. Perhaps the approach lies in how to attract business environments to use these paid tools, perhaps by offering better tools or more competitive prices, but trying to reap those benefits from activities in laboratory environments or for personal use, which do not generate profits, is not the best option, in my opinion...

[samus-aran]

Hey @alexaka1 👋

Is the discussion considered closed, or should we keep sharing feedback here?

No this discussion is still very much opened. 👍

They've been quite inconsistent about things. Often when they make a release and a blog post they create a discussion about their new announcement. But they didn't this time.

Thanks for creating the individual discussion @jsoref. It was decided that since the release was a combination of things that we didn't create a new discussion for each of the shipped fixes. But I can understand the confusion and we'll consider a better way to highlight that in upcoming release/update announcements as there will be more to come soon.

[jsoref]

@queenofcorgis please remind this user not to use AI to spam github discussions

[Tensho]

Hello, chaps 👋 Do you have actions exclusion list from SHA pinning enforcement at organisation level feature in the roadmap? We have SHA pinning enforcement enabled at GitHub organisation level but want to use reusable workflows and actions from a 3rd party vendor we trust.

[cryptic-mystic]

Key question is can ya'll make these improvements without nuking your availability & uptime. So far the answer is no.

[orbikm]

A few more:

Support links that would pre-fill a workflow's dispatch inputs (with query parameters), so we could generate valid links for others to continue the process in another workflow as needed.

---

(Workaround recommended below)
I would like a way to have a job always execute, even when specifying to only re-run failed jobs. We use unique identifiers for our runs, which we later use as input on other workflows. We generate and display this information in the Job Summary step. If the run then fails, we want to re-run only the portions that failed, but now the Unique Identifier in the summary is incorrect / outdated. This has led to confusion in the past. We'd like to have a way to update it. OR, if GH provided a consistent way to grab a truly unique ID for the specific workflow run, as opposed to mashing the various IDs together ourselves.

[jsoref]

You should be able to burn in the -attempt number into your things and have a job that needs all the other jobs so that it runs last and have it generate a current id. (check-spelling includes /attempt/ things in its links because it expects to be rerun.)

Introducing something else is bound to be abused in bizarre ways that I don't look forward to tripping on.

[orbikm]

Interesting. I will give that approach a try, it sounds like it would work. I would be fine using that as a solution if it works as I think it will. Thanks

[nicholasmaheshwari]

Personally I would love to see dynamic inputs, where I can start off with a simpler choicebox type first input (or any type of input really), which depending on the choice, creates / eliminates other inputs. Would be very helpful for displaying advanced configuration options more effectively, as opening a GHA and seeing 20+ inputs pop up is often overwhelming for newer users of an automation written for some of our infrastructure.

[nebuk89]

Yep - it's solid feedback. There is an open discussion on this and we are tracking it. We did the increased inputs to start and this is on the list along with secrets as an input type