Earlier quoted context omitted.
I don't agree. I've used other CI platforms that get UX a lot more right.
Which ones?
Circleci
We use GitHub Actions to build GitHub
81–90 of 98 posts
Re: We use GitHub Actions to build GitHub
#82I prefer CircleCI over GitHub Actions.
Re: We use GitHub Actions to build GitHub
#83GitHub Actions has a lot of basic usability issues, none of which are fatal but all of which irritate me on a daily basis. Let's start with the first and simplest: Why did my build fail? You'd think this should be front and center. Yet, the UX is "click through a couple links, then wade through thousands of lines of log output". In practice this is "download the logs and grep them for text strings like FAILURE". The…
This is why UI is hard. In a parallel universe they made the re-run jobs button like you want, and there's some person at the top of the Hacker News comments in that universe making the complaint that it's too hard to tell what the buttons do, and that only the common path of rebuilding failed builds is easy and once you need to do something uncommon it becomes irritatingly complex.
> This is why UI is hard.
Is it though?. I mean, pretty much all mainstream CICD services do this right out of the box. GitLab does this so well it's even totally transparent and never an issue.
How come GitHub actions, which succeeded all of its alternatives, managed to turn a solved problem into a constant source of headaches?
Re: We use GitHub Actions to build GitHub
#84Re: We use GitHub Actions to build GitHub
#85GitHub Actions has a lot of basic usability issues, none of which are fatal but all of which irritate me on a daily basis. Let's start with the first and simplest: Why did my build fail? You'd think this should be front and center. Yet, the UX is "click through a couple links, then wade through thousands of lines of log output". In practice this is "download the logs and grep them for text strings like FAILURE". The…
> because of some flakey third-party service I've started building in auto retries to the CI scripts for this type of thing, at least once it annoys me to a certain extent. The most glaring and unavoidable ones that come to mind across several projects are external certificate time stamping services. I generally hate this type of thing: retry mechanisms are a lazy band-aid that can mask real problems. But at the same…
> I generally hate this type of thing: retry mechanisms are a lazy band-aid that can mask real problems.
They can, but beyond the old "it broke once it deployed" obvious pattern, 9 out of 10 times retries only sidestep basic nuisances from transient errors such as a request timing out.
Re: We use GitHub Actions to build GitHub
#86GitHub Actions has a lot of basic usability issues, none of which are fatal but all of which irritate me on a daily basis. Let's start with the first and simplest: Why did my build fail? You'd think this should be front and center. Yet, the UX is "click through a couple links, then wade through thousands of lines of log output". In practice this is "download the logs and grep them for text strings like FAILURE". The…
My favorite issue is that when the service is down it just doesn't run jobs or notify in any way that they are not being run. No "error" state in PR view or anything, let's just skip tests.
Re: We use GitHub Actions to build GitHub
#87I've used GitHub Actions quite extensively now, across infrastructure automation, Python CI/CD, and iOS CI/CD, and while not perfect, it's the best platform I've used for this stuff so far. Compared to Jenkins it needed far less maintenance. Compared to CircleCI it felt much easier to work with and to build reliable pipelines due to the locking primitives it provides, and compared to Semaphore I found it easier to un…
We use GitLab CI for internal code and GitHub Actions for public code, and are generally happy with both. GitHub Actions emphasizes reusability and composability around “actions” as installable packages suitable for a “marketplace” model. This works well, but once you deviate from a standard action, changing its behavior requires learning (or re-learning every six months) the GitHub Actions DSL to make it do what you…
I forgot to mention GitLab CI, but in my experience, much like with Travis CI, it is as you say lower level. I do not find that to be a good thing.
Rather than lower level being faster as it is with code, generally with CI we want to raise the abstraction level so that it's easier to make use of things that make CI run faster – parallelism in workflows, caching etc.
As for reliability, I also found GitLab CI lacked the concurrency control caching primitives necessary to trust continuous delivery pipelines.
I found you could either write a slow correct pipeline, or a faster but fundamentally unsafe one.
Re: We use GitHub Actions to build GitHub
#88I've used GitHub Actions quite extensively now, across infrastructure automation, Python CI/CD, and iOS CI/CD, and while not perfect, it's the best platform I've used for this stuff so far. Compared to Jenkins it needed far less maintenance. Compared to CircleCI it felt much easier to work with and to build reliable pipelines due to the locking primitives it provides, and compared to Semaphore I found it easier to un…
It's definitely more pleasant to use than Jenkins, but Jenkins is as painful as it gets. 90% of the times it's some ancient setup that nobody knows how it works. And the amount of hands-on required to keep in working is waaaay higher than other CI pipelines. Circle CI is also not very nice at all. Things like GitLab CI or Sourcehut Builds are sooo much simpler, lighter and faster in comparison.
Jenkins sucks from a UI perspective, and from a maintenance perspective, but it's very powerful in ways that most other CIs are not.
The classic example for us was concurrency control. We did continuous delivery, and so it's critical that you're not trying to release the `master` branch multiple times concurrently, especially when database migrations might happen, etc.
With Jenkins you could quite easily say "only 1 of this job at a time", but this wasn't (at the time) a feature of CircleCI, GitLab, or Travis. GitHub Actions added it about 2 years ago I think, and Semaphore has had something similar for a while.
While I agree Jenkins is painful, having this feature and the reliability it brought reduced pain significantly. CircleCI not having this feature, for us, caused a lot of pain.
Re: We use GitHub Actions to build GitHub
#89I wish GitHub Actions worked more like Drone. Just run commands in specified Docker containers. None of this weird probably dangerous in-channel signaling via STDOUT. Completely skip the base level OS with a billion tools people might want pre installed that shifts over time, that’s just asking for your build to break while you’re on vacation. It’s a very Microsoft way to do it. It’s messy.
I know GitHub Actions has a built in opinion to kinda run like that, but I have had a ton of problems with permissions in that mode and it incurs an unavoidable 30 second overhead as it sets up Docker, every single time. Which for a 2 second unit test suite is an eternity.
I loved Drone CI when it was OSS. I contributed to Drone, I loved Drone with my whole heart. Drone stopped loving me; they pulled the rug out from under me, made my contributions non-free, and charged more than me and my company could possibly justify to use my own contributions. I learned the valuable lesson of why you don’t want to sign a CLA the hard way.
I am using GitHub Actions and I am not particularly happy about it. GitHub Actions: “It’s better than Jenkins and about on par with Travis”
Re: We use GitHub Actions to build GitHub
#90I wish GitHub Actions worked more like Drone. Just run commands in specified Docker containers. None of this weird probably dangerous in-channel signaling via STDOUT. Completely skip the base level OS with a billion tools people might want pre installed that shifts over time, that’s just asking for your build to break while you’re on vacation. It’s a very Microsoft way to do it. It’s messy. I know GitHub Actions has…
I've always seen a CLA as "we dont really want to take your contributions".
Which is fair enough, but yea, dont be surprised if they take it closed source.