GitHub Community
Let’s talk about GitHub Actions 💬 ✨ #181437
Replies: 28 comments 42 replies
-
I am very excited about this! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
The link does not work, but anything to prevent committing the dist file in the repository would be preferred. |
Beta Was this translation helpful? Give feedback.
-
|
community/maintainers is a semi private repository.
|
Beta Was this translation helpful? Give feedback.
-
|
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 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 |
Beta Was this translation helpful? Give feedback.
-
|
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. 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 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 |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
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...) |
Beta Was this translation helpful? Give feedback.
-
|
👍 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! |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Let me know if you didn't get the email @jsoref. Excited to chat! |
Beta Was this translation helpful? Give feedback.
-
|
I can't find it. I sent an email... |
Beta Was this translation helpful? Give feedback.
-
|
The ways forks are handled is so many disasters.
|
Beta Was this translation helpful? Give feedback.
-
|
cc @salilsub this is a new one to me good catch |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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.. |
Beta Was this translation helpful? Give feedback.
-
|
Would love support for updating the run-name throughout the entire job, similar to the action summary: Other recommendations:
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Renaming and concurrency are things I think we just need to get done in the next 6 months now 👍 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 |
Beta Was this translation helpful? Give feedback.
-
|
@jsoref run cancelled notifications - yep, we just need to do, agree. |
Beta Was this translation helpful? Give feedback.
-
|
👋 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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
There are two drop downs:
There's also a placeholder for the main body, there's nothing wrong here ✅.
|
AccessibilityBeta Was this translation helpful? Give feedback.
-
|
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).
Oft.
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.
Reading your feedback you specifically naming the dropdowns and not pre-text e.g
☝️ 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.
Fair call out. Most of these naming conventions was from the migration of discussions from the other Actions repos detailed here:
As for label explanations we can certainly add in a link to their descriptions from the discussion template so folks know what they mean.
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. |
Beta Was this translation helpful? Give feedback.
-
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:
Here's a real flow: What do I do?
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.
Moderator's Edit: Set width of images for easier reading. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
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:
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 PRs1 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 Footnotes
|
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
The runner-images repo has mentioned this in the readme for two years:
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. 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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Would you be up for something like Fedora? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 Simplest fix: |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
This is an ask thats in a few different forms and we totally hear it. 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!) |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I think 2380 is still open? Or can you confirm that is fixed? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/orgs/community/discussions/44490 + https://github.com/orgs/community/discussions/13690 |
Beta Was this translation helpful? Give feedback.
-
|
Yep, these two I or someone on my team needs to really dig into. I want to do these and be sure we aren't introducing a 'new risk like pull_request_target'. |
Beta Was this translation helpful? Give feedback.
-
|
My enterprise recently started migrating towards self hosted runners. Not because it's cheaper or faster but because that was the best/only way for us to get control over the outbound network so we can uphold security standards like using our private npm registry instead of going to the public one directly. We don't want this additional management and start up speed of standard GitHub hosted runners is really something we are going to miss. So if you could add that feature we will gladly migrate back. |
Beta Was this translation helpful? Give feedback.
-
|
You can use a custom Azure VNet to control the network configuration: https://docs.github.com/en/enterprise-cloud@latest/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/configuring-private-networking-for-github-hosted-runners-in-your-enterprise But starting a custom GitHub runner also takes some minute, about a minute. Also, the bicep file is not published to a repository to automate the IP ranges... BTW, unfortunately, VNet is not supported by Codespaces. |
Beta Was this translation helpful? Give feedback.
-
|
Isn't the vnet only available for the github larger runners? Because we didn't like those because it needs additional management of runner groups of the sort and we mostly build on AWS so we went with codebuild instead. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah not the first time we have heard this <3 I have dreams of building a wireguard style solution to AWS or similar. I would love to know more about why runner groups are a blocker here, is it the naming of the machines or something else that makes this hard for you? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry I miss typed it I meant the additional management of larger runners. We rather have something that we setup once and it autoscales instances with a min and a max amount and we don't have to setup individual runners. We also don't have any azure experience so for us to manage the vnet in azure is also a pain point. For codebuild we can have a dedicated aws team to manage the network for us. If we could deploy and control the VNET via de github UI to abstract the azure specific stuff away we could manage that. |
Beta Was this translation helpful? Give feedback.
-
|
I would love to see better concurrency handling, the current situation is very unsatisfying. |
Beta Was this translation helpful? Give feedback.
-
|
Do you think we should have something like a 'dont' cancel' or should we allow folks to specify a queue depth? Or something else here 👀 |
Beta Was this translation helpful? Give feedback.
-
|
There is already the |
Beta Was this translation helpful? Give feedback.
-
|
Queue depth is certainly the easiest to reason through, right now there's a magical queue depth of In general, being able to queue would be nice. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Multi-choice input is one I am trying to see if we can do 'pretty fast' as it feels really reasonable and like a 'thing we can just do'. The only thing that we might end up with on the path to doing it is better errors for payloads that are just in total too big for workflow_dispatch. That said I think even adding this they should be extremely rare.. so maybe we ship this and come back to that error handling after Pre and post in composite Actions I know is something that @salilsub in my team keeps poking on as well, I think this would come after parallel steps for us but the re-pointer to it is awesome thank you. Support referencing env context on server, yep... around 1.4% of our failed parses today are due to this which sucks. Agree we just need to do this, we have an internal issue and it feels like a great candidate going into April/May after our first chunk in the blog that again 'we should just do' <3 |
Beta Was this translation helpful? Give feedback.
-
|
Fwiw, I have uses for pre/post. I've even run across microsoft repositories that used local actions that failed to run pre/post because of things. I'd have to find them, it was probably an Azure org workflow. |
Beta Was this translation helpful? Give feedback.
-
Note that while I have lots of complaints about lots of actions, this isn't really at the top of my list because I can at some minor expense workaround it, but on behalf the community...
|
Beta Was this translation helpful? Give feedback.
-
|
Please consider implementing the suggestions in https://github.com/orgs/community/discussions/49648, this would be a big improvement for debugging and general visibility. |
Beta Was this translation helpful? Give feedback.
-
|
Most of my points are regarding GitHub Enterprise Server (on premise), as that is the majority of our actions.
|
Beta Was this translation helpful? Give feedback.
-
|
The pricing change discussion states:
Is there a plan to address other architectures for self-hosted runners? Such as: https://github.com/orgs/community/discussions/167009 ? We are providing ppc64le and s390x runners via IBM cloud today, however we would appreciate some more collaboration to make sure our self-hosted runners can continue to function properly. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
More options to self-host caches. It's a problem when builds are slower with caching than without. |
Beta Was this translation helpful? Give feedback.
-
|
There are two things I'd love to see resolved:
I'd also love much better analytics, etc. |
Beta Was this translation helpful? Give feedback.
-
|
Disclaimer: I work at Datadog, but this request isn’t just for my company. It reflects feedback from dozens of GitHub Actions users we’ve spoken with over the past few years. There’s a long-standing need for reliable access to a job's check run ID exposed through default environment variables so customers can properly correlate GitHub Actions runs between Datadog CI Visibility and Test Optimization. This correlation works seamlessly for other CI providers like GitLab and Jenkins, and customers consistently highlight the value. GitHub Actions is the only major CI provider where this gap still exists. Today, we can partly rely on brittle workarounds that function for narrow cases but aren’t sustainable at scale. An upstream fix in the Actions runner would resolve this cleanly for everyone. There is already a PR addressing the issue and ready for review: actions/runner#4053. Thanks for considering it, and happy to provide any additional details if helpful! |
Beta Was this translation helpful? Give feedback.
-
It's hard to know whether this is within the boundaries of the |
Beta Was this translation helpful? Give feedback.
-
|
I'd like for a job to programmatically mark itself as "skipped" (the "canceled" behavior is such that you trigger these annoying notifications and ❌ states) -- it's really hard to mark as skipped from a composite action.
What I do instead these days is: It isn't as satisfying as the skipped state on checks, but the effort required to do something else was prohibitive, and as noted it was too fragile. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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
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.
Beta Was this translation helpful? Give feedback.
All reactions