actions-runner-controller VS jenkins-std-lib

To set-up the self-hosted runner, an Action Runner Controller (ARC) and Runner scale sets application will be installed via helm. This post will be using Azure Kubernetes Service and ARC that is officialy maintained by Github. There is another ARC that is maintained by the community. You can follow the discussion where github adopted the ARC project into a full Github product here

Before this we were using https://github.com/actions/actions-runner-controller but that's running on K8s instead of VMs. So along with common limitations of running CI jos in K8s/container, it cannot have exactly the same environment as the official GitHub runners. Maintaining a K8s cluster was also very difficult.

ARC is great for running GitHub Actions on Kubernetes:

https://github.com/actions/actions-runner-controller

Almost all of our cicd, builds run on GitHub. I'm talking cypress tests, deployments via terraform and helm to over 25 environments, all backend tests, daily test runs etc. Overall we were racking up a cost of almost 20k on GitHub. With the ARC deployed and using spot instances I think our total infrastructure costs went up about 4-5k even though we added more actions. If we switched back to their runners we'd probably be around 25k at this point.

What else needs to be moved to my artifactory (charts - https://github.com/actions/actions-runner-controller/tree/master/charts ) - if so tar or entire folder or anything else ? ) What should the above steps correspond to?

You need to use the steps in the repo instead of the steps on the docs if you're using enterprise server.

Honestly not a fan of Github docs.....I feel like the ones in the repo are much clearer and easier to understand/read.

Its pretty easy to set up honestly. Deploy this on your k8s cluster https://github.com/actions/actions-runner-controller and a runnerDeployment and youre good to go.

Trying to use the Actions Runner Controller (https://github.com/actions/actions-runner-controller) to utilize self-hosted runners. I keep getting this error on the controller.

I'm convinced one of (or a combination) of things is happening here in regards to authentication. This GH enterprise account is configured with SAML. I feel like that is a valid data point. I'm using https://github.com/actions/actions-runner-controller as a reference guide for what I should be doing. I suspect whoever is Owner of this organization has modified what I can do as a user. The steps in the doc where I can actually Install the Application isn't available to me. When configuring the GitHub App I'm given two options. I select the option for "this account only" knowing the documentation says it is possible to use this Github App with a repo in the Organization as long as I have Admin privileges or I'm the owner.

> On a previous team I had used Concourse CI to some extent, but I wasn’t really blown away by the experience. Travis and Circle were mentioned. I was a fool. I should have committed to seriously researching some of the contenders and making a more informed decision, but I lacked the willpower and the discernment.

The whole post can be summed up as he had very little CICD experience. Made lots of beginner mistakes, which is easy to do in Jenkins. Then decided to write a post where all his complaints about Jenkins are not only wrong but are the issues that plague all the other CICD tools.

> So instead of writing Bash directly, you’re writing Bash inside Groovy

Why are you doing that? You have a fully featured programming language and you are running `sh('npm install')`. You could do this instead https://github.com/DontShaveTheYak/jenkins-std-lib/blob/mast... . How is bash inside of YAML better?

> The trouble is: Groovy is a much, much worse language for executing commands than Bash. Bash is interpreted, has a REPL that is great for experimentation, does require a ton of imports, and has lightweight syntax. Groovy has none of these things.

Groovy has a language server, linters and a vscode IDE plugins. They are probably not as stable or full featured as the bash ones, but they are available and very few take advantage of them. Again, how is YAML+Bash better?

> The way that developers test their Groovy steps is by triggering a job on the remote Jenkins server to run them. The feedback loop is 2 orders of magnitude slower than it is for just executing Bash locally.

This is a rookie mistake. For about 60-75% of pipelines you can run them locally in a docker container on your local machine. You can even set up hot code reload so as you change your pipeline the Jenkins reloads it. You can also configure the job to kick off a build when it reloads the code. When Jenkins is configured correctly it has the fastest feedback loop of any CICD tool on the market. GitHub actions comes in a close second since it can also be run locally but you cant run a "clone" of what you run in production, like having the same secrets, so it gets second place. Beside Jenkins and GitHub actions, I dont know of any solutions for the other tools.

You can run a GitHub action on Jenkins. It's a very deep and complex system. It's like an iceberg and so many engineers dont leave the surface before deciding it sucks and one of the YAML CICD tools is better. Sure the YAML alternatives are EASY to get started with and to do basic stuff with. But they are Terrible at anything complex. While Jenkins is not easy to get started with, once mastered, you can build complex pipelines with ease.

I get that I'm a Jenkins fanboy. Most of the things I mentioned above, I either contribute to or I'm the author of. I know Jenkins has issues. I know it has hurt lots of people, I read the complaints online. But it's still the best out there. The best software in the world is not written in bash or yaml and the same is true of the best CICD pipelines in the world. It's a shame very few people get to see/use those pipelines.

With Jenkins you can still run your favorite GitHub actions. https://github.com/DontShaveTheYak/jenkins-std-lib/blob/master/jobs/github/actions/step_example.groovy

This library has a lot of helpful features https://github.com/DontShaveTheYak/jenkins-std-lib , one of my favorites is being able to run GitHub actions natively in Jenkins pipelines.

Here is an example using s6 overlay https://github.com/DontShaveTheYak/jenkins-std-lib/tree/master/docker/prod

Run a Jenkins locally in docker. I use a vscode dev container for this. https://github.com/DontShaveTheYak/jenkins-std-lib/blob/master/.devcontainer/devcontainer.json

I do my best https://github.com/DontShaveTheYak/jenkins-std-lib

If you use Jenkins and want to try actions then check out https://github.com/DontShaveTheYak/jenkins-std-lib

It let's you run actions on top of Jenkins.