With Github's introduction of free Team plans, one may be tempted to switch from other hosted git solutions like Gitlab or Bitbucket to Github. However, it is good to be mindful that Github Actions' incompleteness may force you to use a third party CI solution.
Anyone can deploy to production
I pointed this out in my previous post regarding Bitbucket Pipelines and CircleCI. Basically, Github Actions (and Bitbucket Pipelines) allows you to declare environment variables that you can use in your build scripts. These typically contains access keys to your prod/dev environments. Without any restrictions on accessing these keys, any committer to your repository can use them in the build script and deploy to production. Yes, that intern you hired can now deploy to production!
Bitbucket fixed this by introducing 'Deployment Permissions' in their Premium plan. Github though has no plans to fix it.
No Docker Layer Caching
This is so fundamental, its absence is shocking. Docker layer caching is used to speed up docker builds, to reduce both build time and cost. All modern CI systems have it. Github seems to have no plans to add it either.
No 'Manual' Triggers or Approvals
No option to manually trigger a job or step. When you actually need this, there are no workarounds other than just switching CI systems completely. All popular CI solutions have this.
No way to 'rerun' builds
Surprisingly enough this fundamental feature is not present.
No option for bigger machines
Github has chosen to sidestep this by offering 'Self-hosted runners'. However, if you want a fully SaaS CI solution and you want to speed up your builds, you cannot choose to pay Github for a bigger box to run your builds on.
Github Actions feels like a neglected product. It does the bare minimum to be a CI product. If you use Github right now, you will pretty much be forced into using a third party CI solution.