GitHub Actions limitations and gotchas
We&#x27;ve been loving GHA: CI&#x2F;CD-as-code, pull requests capture deploy history (CI, stage&#x2F;restage, deploy), and labeling a PR with &#x27;release&#x27; is enough to generate our on-prem + multi-cloud artifacts.<p>Our main gotchas are roughly:<p>- GH-hosted runners have too little RAM&#x2F;HD for big docker software. They push you to self-hosted runners for that, which is fine in theory, but GHA&#x2F;Azure doesn&#x27;t actually support serverless runners, so that falls flat in practice. We don&#x27;t want to be turning machines on&#x2F;off, that&#x27;s GHA&#x27;s job. We experimented with GHA -&gt; Packer -&gt; Azure for serverless, but it was slow and Packer frequently leaves zombie machines, so we went back to tweaking the low-RAM runners provided by our enterprise plan.<p>- Security: We want contactors etc. to be able to run limited GHA CI jobs and use that quota, but not higher-trust GHA CD ones. This is tricky at a configuration level. Ex: It seems like we&#x27;d need to funny things like main repo for CI w&#x2F; CI secrets, and a separate repo for CD w&#x2F; CD secrets, and only give untrusted folks access to the CD-cred repo. We&#x27;ve thought of other possibilities as well, but in general, it&#x27;s frightening.<p>- Big Docker images: We do spend more time than I&#x27;d like messing with optimizing Docker caching as GPU containers are embarrassingly big (we use dockerhub vs github&#x27;s due to sizes&#x2F;pricing&#x2F;etc), think both multi-stage containers + multi-step jobs (monorepo&#x2F;microservices).  I think they&#x27;re in a good position to speed that up!<p>I&#x27;m optimistic about these, but tricky to align with MS&#x2F;GH PM personal team priorities :)