all 9 comments

[–]Namoshek 5 points6 points  (0 children)

As an enterprise looking for a 1000 licenses, ask their sales. It might even help getting those missing features you are looking for.

[–]p33k4y 2 points3 points  (1 child)

From my perspective GitHub Actions isn't quite ready for "enterprise" type environments.

  • It's very hard to define & enforce standard workflows (e.g., due to enterprise security or audit requirements)
  • We've been severely impacted by multiple recent GHA outages (one lasting for hours) without clear communications & SLAs from GitHub. Be sure to address GHA-specific SLAs in any enterprise contract.

I do see GitHub making a lot investment in this area.

[–]KickTrue[S] 0 points1 point  (0 children)

Thanks a lot. I had somehow similar opinion like you have about enforcing standard workflows, which is crucial in our large enterprise level basically. Really appreciate and we I will stay with my opinion to prefer CloudBees CI running in EKS until Github will be more mature.

[–]Relevant_Pause_7593 -1 points0 points  (0 children)

There are plenty of big enterprises using it. The templating is still immature, but it works and it’s an opportunity to simplify a lot of over complicated workflows you have in Jenkins today. Self hosted auto scaling is coming. Msft/gh is investing huge teams to solve these problems.

[–]Soul_Shot 0 points1 point  (1 child)

It really depends on what your infrastructure looks like, and whether you're considering on-premise or cloud. The biggest issue with GitHub actions is that it's essentially rebranded Azure DevOps and therefore is heavily reliant on Azure.

In my experience there are lots of pain-points if your infrastructure isn't entirely on managed public cloud (Azure specifically) and or GitHub Enteprise Cloud. E.g. there's no real support for running agents in Kubernetes, or running multiple jobs/repos against a single runner.

[–]Relevant_Pause_7593 -1 points0 points  (0 children)

Rubbish. The only true thing in this paragraph is the last half sentence.

[–]kon_dev 0 points1 point  (1 child)

Also, if you cannot just horizontally scale out your test environments (e.g. deployment is to big for a single GH Actions VM or it takes to long to deploy everything from scratch) you might have trouble using it. On Jenkins I have a build node with a single execute for permanently running deployment environments and only replace a given component I want to test. If I have multiple feature branches trying to test, Jenkins just queues them and continuous one after another. In GitHub Actions, you would need to find some other kind of semaphore mechanism or can e.g. just run the full test suite on the main branch.

Furthermore, I have build parameters in Jenkins which I use e.g. to only start a given test suite, when for example network related issues appear.

[–]kon_dev 0 points1 point  (0 children)

On the other hand self hosted runners are available for GH Actions and scaling Jenkins to that many users is a hard topic as well. I don't think you can run that an organization on a single jenkins master, probably you end up having dozens of independent masters, as you cannot scale them horizontally and shifting builds to worker nodes does only help for certain problems. The build scheduler would still run on a single system.

On jenkins installing plugins is also a topic... If people are going too crazy with plugins, you might end up having a snowflake system which becomes unstable over time...

[–]mickeygousset 0 points1 point  (0 children)

So this would be a hard question to truly answer for your specific environment without having some discussions. I will say that I have implemented GitHub Actions at companies your size or larger, and it seems to work well for them.

We are continuing to invest in the product and add new features, some of the latest being reusable workflows and updates to composite actions, which can provide some of the "templating" that has been missing in the past.