3 ms·

Sounds like you have the same pain points as everyone else; you're just more willing to ignore them. I am with the author - we can do better than the status qu

Sounds like you have the same pain points as everyone else; you're just more willing to ignore them. I am with the author - we can do better than the status quo!

raffraffraff 2y ago
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.
- Marsymars 2y ago
  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.
  - sgarland 2y ago
    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.
tobinfekkes 2y ago
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.
- IshKebab 2y ago
  > 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.
- michaelmior 2y ago
  > 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 https://github.com/fastlane/fastlane
dkdbejwi383 2y ago
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.
- ironmagma 2y ago
  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?
  - dkdbejwi383 2y ago
    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.
    - IshKebab 2y ago
      > 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.

Sounds like you have the same pain points as everyone else; you're just more willing to ignore them. I am with the author - we can do better than the status quo!

raffraffraff 2y ago

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.

Marsymars 2y ago
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.
- sgarland 2y ago
  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.

tobinfekkes 2y ago

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.

IshKebab 2y ago
> 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.
michaelmior 2y ago
> 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 https://github.com/fastlane/fastlane

dkdbejwi383 2y ago

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.

ironmagma 2y ago
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?
- dkdbejwi383 2y ago
  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.
  - IshKebab 2y ago
    > 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.