GitHub Community
Let’s talk about GitHub Actions 💬 ✨ #181437
Replies: 47 comments 61 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.
-
|
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.
-
|
XD |
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.
-
|
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.
-
|
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.
-
|
Update: I think Alpine Linux is a better option now that i have seen |
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 @nebuk89? |
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.
-
|
For skipped jobs, output state of variables that caused the skip. It can currently be very hard to determine why a specific job may have been skipped if there's multiple conditions, and what we get right now is not very helpful in terms of logs / output on the run itself. |
Beta Was this translation helpful? Give feedback.
-
|
Make it easier to handle output values from Matrix jobs. We would be using Matrix strategy in several areas if there were a usable output mechanism integrated. If I recall correctly, currently, whichever matrix execution writes to the output last overwrites the entire output. There are other discussions on the topic, but I've ran into this limitation and it was quite frustrating and made us just unroll the matrix into hand-coded jobs with different parameters, which is a shame. |
Beta Was this translation helpful? Give feedback.
-
|
The workaround for this is to have each job in the matrix upload an artifact named with a matrix suffix containing your outputs and then download all the artifacts based on the matrix prefix. jobs:
build-arch:
name: Publish ${{ matrix.arch }}
timeout-minutes: 15
permissions:
id-token: write
contents: read
strategy:
fail-fast: false
matrix:
include:
- runner: ubuntu-24.04
name: amd
os: linux
arch: amd64
- runner: ubuntu-24.04-2cpu-arm
name: arm
os: linux
arch: arm64
runs-on: ${{ matrix.runner }}
steps:
...
- name: Generate artifacts
shell: bash
env:
image_id: ${{ steps.push.outputs.image }}
digest: ${{ steps.push.outputs.digest }}
run: |
(
echo "image_id: $image_id"
echo "digest: $digest"
echo "pull_url: $CONTAINER_REGISTRY/$PROJECT_ID/$image_name@$digest"
) > outputs.yml
- name: Upload artifact
uses: actions/upload-artifact@v5
with:
name: outputs-${{ matrix.name }}
path: outputs.yml
combine-images:
name: Combine images
permissions:
actions: read
packages: write
id-token: write
needs:
- build-arch
runs-on: ubuntu-24.04-2cpu-arm
steps:
- name: Collect
id: collect
shell: bash
env:
GH_TOKEN: ${{ github.token }}
run: |
gh run download \
-R "$GITHUB_REPOSITORY" \
-p 'outputs-*'
... |
Beta Was this translation helpful? Give feedback.
-
|
I'm aware of some of this workaround, but it would be preferred to supply an officially supported method for this built into the implementation itself |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, I'd much prefer to have a map so I could do |
Beta Was this translation helpful? Give feedback.
-
|
The most frustrating thing here is that this was supposedly near completion almost three years ago before layoffs. |
Beta Was this translation helpful? Give feedback.
-
|
You made me happy with this post. Together with the already promised updates, here a few features that would save a lot of time and make the workflows less verbose. tl;dr: Working with actions would get a lot less complicated if data and parameter transfer between jobs and workflows was more simple and re-use of all kinds of entities, such as parameters, steps, jobs and workflows was built-in. Actions are versatile but require a lot of overhead, are complicated to develop and test offline. Many things listed below are doable already with complicated workarounds, but getting rid of such fragile contraptions would be a bliss. Random Build Engineer's wishlistWorkflow development
Retries and re-running
Release processGitHub could host project- and repository-specific running numbers, with a bump via API for release versioning without having complicated workarounds or external version databases. This should be independent of the workflow file and run number. It is not always handy to use tags, especially in monorepo with plethora of parallel (pre-)releases. |
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/orgs/community/discussions/106392 + https://github.com/orgs/community/discussions/41705 + https://github.com/orgs/community/discussions/70621 |
Beta Was this translation helpful? Give feedback.
-
|
Regarding Actions Cache: Add a button in the UI to delete ALL caches. While you can use a custom script to delete the caches manually, there is no button in the web UI for such a basic request. |
Beta Was this translation helpful? Give feedback.
-
|
The fact that anchors don't work reliably is driving me crazy: |
Beta Was this translation helpful? Give feedback.
-
|
Connecting a number of things, there's a desire to be able to step through actions, e.g.: 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
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
It'd certainly be nice to have a way to do this. For check-spelling, I have:
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. |
Beta Was this translation helpful? Give feedback.
-
|
I ended up implementing this... It's in: https://github.com/check-spelling-sandbox/check-spelling/actions/runs/21040487174#summary-60500622548
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). |
Beta Was this translation helpful? Give feedback.
-
|
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(I think that info is somewhere in the download logs) |
Beta Was this translation helpful? Give feedback.
-
|
Run label is wrong for local actions:
That line should correspond to:
But the log has a spurious / disconcerting leading |
Beta Was this translation helpful? Give feedback.
-
Required status checks enhancementTouches 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 billingI 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 logicDynamic matrix configurationHaving 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 checksRequiring 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
- arm64If the job is skipped, a single job will report skipped named 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 Clearer inputs for triggers that don't support themYou can add a bunch of inputs to a Proper ternary expressions
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 workflowsCurrently 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 appsSecretless 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
my proposed compromiseNow, 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:
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
this is possible with a job conditional like if: (!github.event.pull_request.draft) |
Beta Was this translation helpful? Give feedback.
-
|
macOS runners on GHE.com. It is currently not supported, but there is also no roadmap item to follow. |
Beta Was this translation helpful? Give feedback.
-
|
Hi all, just wanted to share an update from the Actions team. We've had a few new items released:
We also have a bunch of open items in progress
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:
Thanks! |
Beta Was this translation helpful? Give feedback.
and others
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