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!

[hfhbd]

Any chance to get an update "soon"?

[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

[theSistasheriff]

This might not be the place for questions, so redirect me please if there is a thread for this.

I agree that forks cause problems. I am trying to implement a centralised workflow repo that is dispatched from a GH app. I have found ways to read PRs from repos in my org, but get errors from checkout when a forked branch does pr to main (in the repo it's forked from).

Am I missing something, or is it not possible yet?

[jsoref]

@theSistasheriff you can do it, but you can do:

- uses: actions/checkout@v6
   with:
      repository: ${{ github.event.pull_request.head.repo.full_name }}
      ref: ${{ github.event.pull_request.head.ref }}

or

git remote add fork "$GITHUB_URL/$FORK_REPO_WITH_OWNER"
git fetch fork "$FORK_BRANCH_NAME:safe-branch-name"
git checkout safe-branch-name

or

git fetch origin "$GITHUB_SHA"

-- even though the branch name isn't exposed to your base repo, the sha is magically available (and frankly, it's safer to use than the branch name which can be hazardous).

[theSistasheriff]

Thanks for the example, and answer. I'll try that.

[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

[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

[ffflorian]

My wishlist:

• Job-level variables should be case-sensitive
• Add advanced service container definitions (aliases, variable interpolation, multi-container orchestration)
• Make Docker image entrypoint overrides available
• Make environment variables available inside a job's if: condition.
• Support fine-grained or conditional allow_failure semantics; only binary pass/fail is available
• Complex dependency graphs via needs (optional, parallel, or conditional branches)
• Hide skipped jobs still appear in the UI, decrease noise
• Integrate file existence / change-based rules

[thegravelinspector]

Position-anchored tags: a detection convention

SHA pinning solves the machine problem, but humans can't glance at hex strings. A simple complement: embed the commit position and short hash in the tag name:

v0.18.0-r75-a1b2c3d

The r75 is a slow-moving number anyone familiar with a project will notice if it changes. In this incident, 75 rewritten tags would have shown wildly wrong position numbers — instantly suspicious, no tooling needed.

Full proposal with scripts: https://github.com/thegravelinspector/position-anchored-tags

(Drafted with help from Claude.)

[hfhbd]

GitHub should instead implement immutable tags or, even better, a real binary repository. They did implement a prototype using immutable actions uploaded as a zip file with OCI metadata to the container registry, but stopped the project.

Many other ecosystems like Maven enforces immutable binaries (with PGP signatures) instead of using a mutable git tag without any lockfiles. GitHub actions just checks out the whole repository at the given tag. Nothing more, there is no validation. A new tag convention does not fix the fundamental problems.

https://nesbitt.io/2025/12/06/github-actions-package-manager.html

[jaydiazzz]

I would love to see the previous user flow for github actions be put back. I tend to run multiple workflows in parallel and it's annoying having to go back to the previous page and reload after being redirected to the workflow page. It definitely increases my deployment time.

[Pradumnsaindane]

I completely agree that this change in GitHub Actions UX is frustrating, especially when you’re running multiple workflows simultaneously. The forced redirect to a single workflow run disrupts the flow and introduces unnecessary steps when you’re trying to monitor or trigger several deployments at once.

A simple workaround I’ve found helpful is opening workflow runs in new tabs (using Ctrl/Cmd + click or middle-click). This maintains the main workflow list, ensuring you don’t lose context. While it’s not perfect, it helps maintain visibility across multiple runs without constant back-and-forth navigation.

For a more efficient setup, using the GitHub CLI (gh run list, gh run watch) significantly reduces reliance on the UI. This allows you to monitor multiple workflows in real-time directly from the terminal.

Another long-term solution would be to create a lightweight dashboard using the GitHub API. This dashboard could display all active workflow runs in one place with auto-refresh. This approach eliminates the need to depend solely on GitHub’s navigation behaviour and provides better control over monitoring parallel executions.

Overall, reverting to the previous user flow (or at least making redirects optional) would greatly enhance usability for developers managing multiple workflows.

[edipoferreira]

Tests Dashboard supporting things like junit reports, when?

[pinfloyd]

This is a broader GitHub Actions boundary question I keep running into with AI- and automation-driven workflows.

OIDC claims, permissions, environments, and approvals can describe or constrain workflow context. But when a workflow is about to receive trusted execution context — secrets, cloud identity, deployment authority, or privileged permissions — should there be a separate fail-closed admission decision for that specific execution intent before the context is granted?

In other words: should GitHub Actions treat “workflow/output validation” and “execution-intent admission” as two separate control points, especially for agent-triggered or automation-created workflows?

[dozer75]

I don't know what's happening with GitHub actions now, during the last month (May 2026) running GitHub workflows has been very unstable. We have a daily failure rate of random errors (e.g. related to repository operations like e.g. fetch/pull), GitHub authentication, running custom actions (like azure/setup-helm) fails randomly with random errors. Re-runs often helps, but running a workflow may need 3 or 4 re-runs to succeed. Today we have experienced failures for at least 40% of our runs.

This is unacceptable. We are reliant of lots of automatic workflows, but we spend a lot of time monitoring these because of these failures as a failure impact our environment heavily.

But we are seriously wondering and checking for other solutions than GitHub actions now since we can't thrust them anymore. The problem is that converting the extent usage of workflows and actions to another platform is a huge task.

NOTE: This is not connected to the incident 2026-05-26 as we started to have these problems earlier than that, it may that the incident 2026-05-26 was caused by these issues.

It's also a bit frustrating that you declare the system operational when people clearly expresses that issues related to the incident still exists (I am talking about the runs that is queued that can't be cancelled or anything) and you don't follow up on these even though maintainers are attached to the comments.

But currently, GitHub Actions have a rating of 0/5...

[pinfloyd]

This looks related to the May 26 GitHub Actions incident: GitHub staff acknowledged queue/start failures and “disruptive” workflow markings as symptoms of the outage, and GitHub Status also reported authentication issues affecting Actions run startup and action downloads.

Your point about trust is the important one: for critical workflows, the problem is not only whether GitHub Actions is normally reliable, but whether privileged execution should be allowed to proceed automatically when the execution substrate is degraded, ambiguous, or producing inconsistent control signals.

I have been working on this exact boundary problem from the angle of pre-execution admission: separating “workflow/output validation” from an external, fail-closed admission decision before privileged execution context is granted.

Related reference:
https://datatracker.ietf.org/doc/html/draft-b-external-admission-boundary

The short version is: internal CI policy and retries help, but for high-impact agentic or automation-created workflows, there may need to be a separate external admission boundary that answers: “is this specific execution intent allowed to run now?” before secrets, cloud identity, deployment authority, or privileged permissions are released.

[dozer75]

As I said, this even happened before 26th....

[f46wu]

This simple feature has been requested for many years now: https://github.com/orgs/community/discussions/18001

Please give us some way to hide skipped jobs / workflows in the UI.

[Pradumnsaindane]

I just want to add one thing that if someone is new in the DEVOPS or github action , so what are the things he or she should do . Also if any one is expert then please provide the perfect guide to learn development .
If you want to share personally then please share it to the personal Email .
Email :- psaindane09@gmail.com

[au-williams]

GitHub Actions is failing again with another outage. Is GitHub's recommendation to not use GitHub Actions as an organizations primary CI/CD pipeline? Our production deployment path is blocked while another outage is being investigated (the 4th GitHub Actions outage in 1 month). In the past we have measured success in terms of "9s" aiming for 99.99% - four 9s. As of today, the GitHub Actions pipeline is 99.75% uptime - two 9s. With the high amount of outages lately, are we on track for one 9? 😕 As another user posted above, we're looking at alternatives to GitHub Actions in response.

[ViacheslavKudinov]

Hi
in 2026 schedule event looks more like a "joke"...

Delays can be up to 2 hours...

It is nonsense to "invent the wheel" like AWS EventBridge Scheduler/Lambda/something else to trigger repository_dispatch/workflow_dispatch just to run "cron jobs" on Actions.

[Pradumnsaindane]

Yapp this the issue that is been going through past few days and is happing till now . But the chances will be decreases and it might get resolved in some days.

[audunsolemdal]

I wasn't able to find a discussion re: the new parallel actions capability.

I think this is good for efficiency, however I think it can be further improved

Take for instance this action

      - name: Run hadolint
        if: "${{ inputs.run-image-scan == 'true'}}"
        id: hadolint
        background: true
        uses: hadolint/hadolint-action@2332a7b74a6de0dda2e2221d575162eba76ba5e5 # v3.3.0
        with:
          dockerfile: "${{ inputs.dockerfile-path != 'Dockerfile' && inputs.dockerfile-path || env.default-dockerfile }}"
          format: sarif
          output-file: hadolint-results.sarif
          no-fail: true

1. Even if the if resolves to false - the "build hadolint/hadolint-action step is still run
2. If the if resolves to true - it should ideally implicitly be ran together with the run hadolint step, not blocking other sequential steps . It is a simple docker image pull.

[jsoref]

To avoid pulling things like this when I don't want to pay in the false case, I use a local action that uses: the real action:

https://github.com/check-spelling/check-spelling/blob/main/actions/upload-artifact/action.yml

name: 'Upload a Build Artifact' # normal name
description: 'Upload a build artifact that can be used by subsequent workflow steps' # normal description
inputs: # all the inputs with empty description fields
  name:
    description:
    default: 'artifact'
  path:
    description:
    required: true
  if-no-files-found:
    description:
    default: 'warn'
  retention-days:
    description:
  compression-level:
    description:
    default: '6'
  overwrite:
    description:
    default: 'false'
  include-hidden-files:
    description:
    default: 'false'

outputs: # mapped outputs from nested action
  artifact-id:
    description:
    value: ${{ steps.action.outputs.ref.artifact-id }}
  artifact-url:
    description:
    value: ${{ steps.action.outputs.ref.artifact-url }}
runs:
  using: "composite"
  steps:
  - name: Upload Artifact
    id: action
    continue-on-error: true # from memory, if you want to be able to handle failing in the nested action, you have to do some extra magic, and here, I just really don't care
    uses: actions/upload-artifact@v7 # the real action
    with: # all the inputs mapped
      compression-level: ${{ inputs.compression-level }}
      if-no-files-found: ${{ inputs.if-no-files-found }}
      include-hidden-files: ${{ inputs.include-hidden-files }}
      name: ${{ inputs.name }}
      overwrite: ${{ inputs.overwrite }}
      path: ${{ inputs.path }}
      retention-days: ${{ inputs.retention-days }}

https://github.com/check-spelling/check-spelling/blob/f7a58dae2f6853b38c95e26bac4bcf9698c8e14d/action.yml#L602-L607

      if: ${{ condition }}
      uses: ./../check-spelling-actions/upload-artifact # normally you'd use `./actions/upload-artifact`, but check-spelling is an action so it puts actions outside the working directory
      with:
        name:
          ${{ _normal_argument_to_action_ }}
        path:
          ${{ _normal_argument_to_action_ }}

In this form, if the if: ${{ condition }} evaluates to false, the action runner doesn't think about downloading any referenced action(s).
if the if: ${{ condition }} evaluates to true, then the action runner reads the local action file and resolves all the (non-local) uses: statements.

GitHub has made it fairly clear they don't want to change the process (they in fact want to preload more stuff to ensure things are consistent...).