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.

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"

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).

👍 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!

Any chance to get an update "soon"?

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

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

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

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

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

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?

@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).

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

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

• 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.)

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

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

👋 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.

• 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.

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.

• 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.

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).

• @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.

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!

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

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

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.

Would you be up for something like Fedora?

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.

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

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.

• 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.

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!)

actions/runner#3792 (comment)

I think 2380 is still open? Or can you confirm that is fixed @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

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

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

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

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

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

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