4 ms·

GitHub Actions hands down. Huge amount of community-provided actions, easy to get started, lots of ways to reuse workflows or parts of workflows. Perfect integr

GitHub Actions hands down. Huge amount of community-provided actions, easy to get started, lots of ways to reuse workflows or parts of workflows. Perfect integration with GitHub obviously.

mikercampbell 4y ago
I just implemented my first CI action on GitHub two days ago and can't wait to do it again. You get deep integration that is hard (at least for me historically) to get anywhere else. I have a monorepo, with builds and deploys for each directory, so if I make changes to only 1 of my n-many directories, it only builds and deploys for that 1. But with things like Vercel, Netlify, Render, Heroku (rip lol), and others having built in CI, it leads to interesting conversations around centralized CI (GitHub Actions) vs decentralized CI (aforementioned vendors). I hadn't realized the difference between the two before now, but they have advantages and disadvantages.
mountainriver 4y ago
Second this, I wish it wasn’t so tied to a vendor but it’s really well built
sngz 4y ago
I'm actually in process of moving our team's CI/CD back to jenkins from github actions. I can see github actions working well for a startup to midsize company but my current project working with a big enterprise company with corporate networks and limitations has made it a nightmare.
- ggktk 4y ago
  You can self-host a Github Actions Runner, you will be able to access the host machine's network from your workflows.
  - sngz 4y ago
    yes we have one self hosted runner right now to bypass a few of the problems we had. Going through the corporate bureaucracy to get the runner running in the first place was a nightmare, and it didn't solve all our problems, and now we're also responsible for patching and doing all the paperwork for that runner. Which was the same problem we had with Jenkins in the first place, just without all the other headaches. If I have to patch and secure it anyways with the security team breathing down our necks every other week I rather stick with Jenkins.

GitHub Actions hands down. Huge amount of community-provided actions, easy to get started, lots of ways to reuse workflows or parts of workflows. Perfect integration with GitHub obviously.

mikercampbell 4y ago

I just implemented my first CI action on GitHub two days ago and can't wait to do it again. You get deep integration that is hard (at least for me historically) to get anywhere else. I have a monorepo, with builds and deploys for each directory, so if I make changes to only 1 of my n-many directories, it only builds and deploys for that 1. But with things like Vercel, Netlify, Render, Heroku (rip lol), and others having built in CI, it leads to interesting conversations around centralized CI (GitHub Actions) vs decentralized CI (aforementioned vendors). I hadn't realized the difference between the two before now, but they have advantages and disadvantages.

mountainriver 4y ago

Second this, I wish it wasn’t so tied to a vendor but it’s really well built

sngz 4y ago

I'm actually in process of moving our team's CI/CD back to jenkins from github actions. I can see github actions working well for a startup to midsize company but my current project working with a big enterprise company with corporate networks and limitations has made it a nightmare.

ggktk 4y ago
You can self-host a Github Actions Runner, you will be able to access the host machine's network from your workflows.
- sngz 4y ago
  yes we have one self hosted runner right now to bypass a few of the problems we had. Going through the corporate bureaucracy to get the runner running in the first place was a nightmare, and it didn't solve all our problems, and now we're also responsible for patching and doing all the paperwork for that runner. Which was the same problem we had with Jenkins in the first place, just without all the other headaches. If I have to patch and secure it anyways with the security team breathing down our necks every other week I rather stick with Jenkins.