Live data from Hacker News

GitHub Actions is slowly killing engineering teams

iankduncan.com

61–70 of 219 posts

Re: GitHub Actions is slowly killing engineering teams

#61
post #16

The internet makes me feel like the only person that doesn't mind Jenkins. Idk it just gets the job done ime.

Nah I don't mind Jenkins either. I think it's unpopular because you can definitely turn it into a monstrosity, and I think a lot of people have only seen it in that state.

Re: GitHub Actions is slowly killing engineering teams

#62

nods . nods again . Yep, this is exactly why we left GitHub for GitLab two years ago. Not one moment of regret. Still, I wonder who is still looking manually at CI build logs. You can use an agent to look for you, and immediately let it come up with a fix.

GitHub has an integrated "let copilot look at the logs and figure out the issue" and I swear it has never worked once for me.

Re: GitHub Actions is slowly killing engineering teams

#63

I agree with all the points made about GH actions. I haven't used as many CI systems as the author, but I've used, GH actions, Gitlab CI, CodeBuild, and spent a lot of time with Jenkins. I've only touched Buildkite briefly 6 years ago, at the time it seemed a little underwhelming. The CI system I enjoyed the most was TeamCity, sadly I've only used it at one job for about a year, but it felt like something built by a…

I used TeamCity for a while and it was decent - I'm sure defining pipelines in code must be possible but the company I worked at seemed to have made this impossible with some in-house integration with their version control and release management software.

Re: GitHub Actions is slowly killing engineering teams

#64
What I find hardest about CI offerings is that each one has a unique DSL that inevitably has edge cases that you may only find out once you’ve tried it.

You might face that many times using Gitlab CI. Random things don’t work the way you think it should and the worst part is you must learn their stupid custom DSL.

Not only that, there’s no way to debug the maze of CI pipelines but I imagine it’s a hard thing to achieve. How would I be able to locally run CI that also interacts with other projects CI like calling downstream pipelines?

Re: GitHub Actions is slowly killing engineering teams

#65
post #47

Earlier quoted context omitted.

Jenkins had a lot of issues and I’m glad to not be using it overall, but I did like defining pipelines in Groovy and I’ll take Groovy over YAML all day.

Jenkins, like many complex tools, is as good or bad as you make it. My last two employers had rock solid Jenkins environments because they were set up as close to vanilla as possible. But yes, Groovy is a much better language for defining pipelines than YAML. Honestly pretty much any programming language at all is better than YAML. YAML is fine for config files, but not for something as complex as defining a CI pipel…

What kills me is when these things add like control flow constructs to YAML.

Like just use an actual programming language!

Re: GitHub Actions is slowly killing engineering teams

#66
post #16

The internet makes me feel like the only person that doesn't mind Jenkins. Idk it just gets the job done ime.

I used Jenkins for years at a previous job - for the longest time it was a confusing mess of pipelines coupled with being a fairly outdated version.

Once it was updated to latest and all the bad old manually created jobs were removed it was decent.

Re: GitHub Actions is slowly killing engineering teams

#67
> GitHub Actions is not good. It’s not even fine. It has market share because it’s right there in your repo

Microsoft being microsoft I guess. Making computing progressively less and less delightful because your boss sees their buggy crap is right there so why don't you use it

Re: GitHub Actions is slowly killing engineering teams

#69
The log viewer thing is what baffles me most.

Back in... I don't know, 2010, we used Jenkins. Yes, that Java thingy. It was kind of terrible (like every CI), but it had a "Warnings Plugin". It parsed the log output with regular expressions and presented new warnings and errors in a nice table. You could click on them and it would jump to the source. You could configure your own regular expressions (yes, then you have two problems, I know, but it still worked).

Then I had to switch to GitLab CI. Everyone was gushing how great GitLab CI was compared to Jenkins. I tried to find out: how do I extract warnings and errors from the log - no chance. To this day, I cannot understand how everyone just settled on "Yeah, we just open thousands of lines of log output and scroll until we see the error". Like an animal. So of course, I did what anyone would do: write a little script that parses the logs and generates an HTML artifact. It's still not as good as the Warnings Plugin from Jenkins, but hey, it's something...

I'm sure, eventually someone/AI will figure this out again and everyone will gush how great that new thing is that actually parses the logs and lets you jump directly to the source...

Don't get me wrong: Jenkins was and probably still is horrible. I don't want to go back. However, it had some pretty good features I still miss to this day.

Post reply on HN