act VS jenkins-std-lib

When it comes to the alternatives to tmate, there is another great debugging tool that you could check out. It is called act and it allows you to run GitHub Actions code on your local machine making debugging even easier. It has its own limitations and some learning curve but overall it is another tool you should use if you can’t fix the CI bugs by connecting directly into the running action with the tmate.

Link: https://github.com/nektos/act

Could you upload your build of GitHub's runner image to Docker Hub?

This would be quite useful for users of other GitHub Actions clones like act [0].

[0]: https://github.com/nektos/act

> These kinds of commit messages are typically an indicator of a broken process where somebody needs to commit to see something happen, like a deployment or build process, and aren't able to assert that stuff works locally.

This is one of my biggest pet peeves with services like github actions. Something running locally like "act" [1] isn't sufficient because it doesn't have everything github has and is extra friction anyway to get everyone to use it for testing.

[1] https://github.com/nektos/act

View on GitHub

If you use Github actions, act is incredibly useful. It can be used to test your GH actions, but also serves as an interface for running tasks locally.

That's something that often is difficult or basically impossible. Except for maybe GitHub actions through Act (https://github.com/nektos/act). I'd still lean to something in the yaml sphere if it eventually would be used in deployment pipelines and such. For example a solution incorporating ansible.

It also seems to me that the argument you make is mostly focused on the building step? Earthly certainly seems focused on that aspect.

I feel I'm being trolled, but I'll bite and accept the resulting downvotes

I don't think treating every mention of act as an opportunity for airing of personal grievances is helpful in a discussion when there's already ample reports of people's concrete issues with it, had one looked at the 800 issues in its repo https://github.com/nektos/act/issues?q=is%3Aissue or the 239 from gitea's for https://gitea.com/gitea/act_runner/issues or whatever is going on with Forgejo's fork https://code.forgejo.org/forgejo/act .

But, as for me specifically, there are two and a half answers: I wanted to run VSCodium's build locally, which act for sure puked about. Then, while trying to troubleshoot that, I thought I'd try something simpler and have it run the lint job from act's own repo <https://github.com/nektos/act/blob/1252e551b8672b1e16dc8835d...> to rule out "you're holding it wrong" type junk. It died with

  [checks/lint]     Failure - Main actions/setup-go@v3

https://twitter.com/mitsuhiko/status/1720410479141487099 :

> GitHub Actions currently charges $0.16 per minute* for the macOS M1 Runners. That comes out to $84,096 for 1 machine year*

GitHub Runner is written in Go; it fetches tasks from GitHub Actions and posts the results back to the Pull Request that spawned the build.

nektos/act is how Gitea Actions builds GitHub Actions workflow YAML build definition documents. https://github.com/nektos/act

https://twitter.com/MatthewCroughan/status/17200423527675700... :

> This is the macOS Ventura installer running in 30 VMs, in 30 #nix derivations at once. It gets the installer from Apple, automates the installation using Tesseract OCR and TCL Expect scripts. This is to test the repeatability. A single function call `makeDarwinImage`.

With a Multi-Stage Dockerfile/Containerfild, you can have a dev environment like xcode or gcc+make in the first stage that builds the package, and then the second stage the package is installed and tested, and then the package is signed and published to a package repo / app store / OCI container image repository.

SLSA now specifies builders for signing things correctly in CI builds with keys in RAM on the build workers.

"Build your own SLSA 3+ provenance builder on GitHub Actions" https://slsa.dev/blog/2023/08/bring-your-own-builder-github

> 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.