GitHub has been in the CI/CD business since 2018 and in general it has become a fairly mature product. For a platform to run your code and automate processes around your repos based on certain triggers, it has become robust for most projects. That said, it still has places I do think it can grow as a service. The following are a few that I feel are fairly realistic of GitHub implementing if they gave their developers the time and resources to implement such (and some are either in progress of being developed / in their backlog).

Immutable publishing of actions

Most jobs start with using the actions/checkout action to clone the repo into the environment. As of right now it is on a 4.x major release and the way to use it is as such:

- uses: actions/checkout@v4

That said, this is just pinned to a git tag, and if there is ever an update to that tag, it will be pulled in. The only way around this is to use a specific git commit's SHA, so that same ref to the checkout action would instead look like this:

- uses: actions/checkout@cd7d8d697e10461458bc61a30d094dc601a8b017

Which makes the CI config a bit uglier in my opinion. Tools like Dependabot or Renovate do support pinning to exact SHAs, but updating according to a standard semver update scheme.

That said, GitHub could just treat actions as actual packages as they do the JavaScript npm registry where versions are immutable. When you publish against the 4.0.0 version, they could implement it such that you can't override that version and the only way to fix such is make a new version.

GitHub has this on their public roadmap: github/roadmap issue #592: Immutable actions publishing, but given it has been since October 2022 since the issue was opened and at the time of writing this post no actual movement seems to have happened, it seems that GitHub does not have a high priority for resolving this issue.

Better Aggregate metrics views

There is no easy way for a user of GitHub to be able to see how they're using GitHub actions at an aggregate. The billing page tells you how many minutes have been used of your plan's quota, and it is split across the 3 different OSes they provide for their hosted runners, but nothing related to what repos are using such.

I envision some dashboard where a user could see at a high level what repos they have access to / contribute to are using GitHub Actions, when they're using it, and links to actual workflows. As of March 28th, there is a public beta of Actions Usage Metrics, but it is only available to GitHub Enterprise Cloud users, and honestly this should be a feature that should be pushed down to all organizations and even individual accounts.

A hack in the time being is using the GitHub API to scan across all of your repos, find ones that have workflows defined, and then do a subsequent fetch against the API for the actual running workflows. That said this could fall apart if you have a large amount of repos as you are stuck to a 5000 requests per hour rate limit using the REST API.