I guess it's possible. But I also don't really have anything to ignore....? I genuinely never have an issue; it builds code, every time.

I commit code, push it, wait 45 seconds, it syncs to AWS, then all my sites periodically ping the S3 bucket for any changes, and download any new items. It's one of the most reliable pieces of my entire stack. It's comically consistent, compared to anything I try building for a mobile app or pushing to a mobile app store.

I look forward to opening my IDE to push code to the Actions for my web app, and I dread the build pipeline for a mobile app.

> I genuinely never have an issue; it builds code, every time.

Well yeah because nobody is saying it isn't reliable. It's the setup stage that is painful. Once you've done it you can just leave it mostly.

I guess if your CI is very simple and always the same you are exposed to these issues less.

> I dread the build pipeline for a mobile app.

I would recommend looking at Fastlane[0] if you haven't already.

[0] https://github.com/fastlane/fastlane

The pain points sound pretty trivial though.

You notice a deprecation warning in the logs, or an email from GitHub and you make a 1 line commit to bump the node version. Easy.

Sure you can make typos that you don’t spot until you’ve pushed and the action doesn’t run, but I quickly learned to stop being lazy and actually think about what I’m writing, and get someone else to do an actual review (not just scroll down and up and give it a LGTM).

My experience is same as the commenter above, it’s relatively set and forget. A few minutes setup work for hours and hours of benefit over years of builds.

The non-solution solution, to simply downplay the issues instead of fixing them. You can solve almost anything this way, but also isn't it nice when things around you aren't universally slightly broken?

I guess I'd disagree that this is "slightly broken". That's just how it works. I don't think there's some universally perfect solution that magically just works all the time and never needs intervention or updating.

> That's just how it works.

It's how it works now. It doesn't have to forever. We can imagine a future in which it works in a better way. One that isn't so annoying.

> I don't think there's some universally perfect solution that magically just works all the time and never needs intervention or updating.

Again you seem to be confused as to what the issue is. Maintenance is not painful. Initial development is.

It probably depends on your org size and how specialised you are. Right now I dislike GitHub Actions and think that Gitlab CI is way better, but I also don't give it to much thought because it's a once in a blue moon task for me to mess with them. But I would absolutely hate to be a "100% DevOps guy" for a huge organisation that wants me to specialise in this stuff all the time. I think that by the end of week 1 I'd go mad.

I don't mind it per se; to me the problem is then that some devs don't bother with basic debugging steps of CI failures - if anything works locally and fails in CI, their first step is to message me - so instead of being "100% DevOps" I spend a pile of time debugging other devs' local environments.

My favorite is when they post an absolutely massive error message, most of which is utterly unrelated, but also the answer to their problem is contained within it.