Let's take a quick tour of the yaks I shaved in my tiny nascent repo that's currently all framework with 0 actual behavior. For context: this is a Rails 7 app bootstrapped with JumpstartPro. So there's lots of behavior courtesy of the framework choice I made. Oh, yes, and tests too!

Yak #1.

Why is my build failing?

Oh, sweet! JumpstartPro has a ci.yml specifying a github workflow set up for ci out of the box. But it's failing. Why?

Oh (forehead slap). Standardrb violations. I can fix that. Done. Green now, right? Wrong.

Yak #2.

Why is my build still failing?

Ah, there's an image file I referenced on a static page but forgot to add. Whoops.

I don't actually care about the image file right now but fine, in the name of a green build I'll go find it and commit it.

So, green now, yes? No. Dang.

Yak #3.

Why is my build STILL failing?

Ah. I put the file in ./app/assets/images but it's being served by a static file so it should go in ./public/images. Someday I will get all of the asset pipeline stuff straight in my head. Today is not that day.

So. Green now? Yes? Yes. But I have questions...

Yak #4.

First question: can I run the same commands locally that I ran in CI?

Nope. Getting a mysterious error. Oh, I recognize this one. It's because I'm running the wrong version of Node. Didn't I upgrade already? This should work? OK FINE NODE YOU WIN.

brew upgrade node

Run now please, yes? No. Denied. Same mysterious error. Why?

Yak #5.

What version of node am I running? 14? WHAT? How. Just...how? OH. Dang.

nvm use 18.13.0

So, it will run now, right?

No, now I'm getting postgres connection errors. Ugh.

Yak #6.

What's up with postgres? Oh, somehow something I did in the last hour killed my local server. OK fine, restart.

pg_ctl start

And now run. TADA! But wait...what are all those errors?

Yak #7.

The errors are from opentelemetry. I configured Honeycomb yesterday. Super easy! Super fast! Very cool! But I only configured things for prod, not my local env. And while I can imagine wanting to see traces on my local env, that's not a yak I want to shave right now.

So how do I only load opentelemetry in prod? (this is not nearly as irresponsible as it sounds...my prod is only used by me).

Ah, got it. Only config the sdk if Rails.env.production?

All green and clean now, right? No.

Yak #8.

The system tests have a failure:

Could not open library 'vips.42'

WTF is a vips? Ah got it. Imagemagick replacement. Do I have vips? No. Simple enough:

brew install vips

Everything is now green and clean right? No. CI is failing again. I left some trailing spaces that standardrb caught.

I really should add a pre-commit hook to run stardardrb --fix...but that's a yak for another day.

Putting down my razor. For now.

I believe that one difference between a junior & senior dev is knowing which yaks to shave.

Personally, I prioritize yaks related to:

1. Having automated tests that run on checkin.

2. Keeping that CI build green & clean so when it fails you know it's for a good reason, and it's (relatively) easy to figure out why.

3. Being able to run that same set of tests locally.

Shaving these yaks wasn't the most gratifying use of time, but it's super important.

Two more yaks that are important to prioritize:

1) Find a way to test locally. It's a complicated system and setting it all up locally is too hard? That's nice. Find a way. Otherwise a single experiment can burn half a day or more.

2) Speed up those test cycles. (Finding a way to test locally is a specific example of the more general speed yak.)

I struggled with the Local Test yak today trying to test my ci config. Got there tho. (yay ssh-add -D)

@testobsessed Amen on local testing. I've spent a day in the shadowlands between local pass and Jenkins fail, with much frustration.
@testobsessed Yes! Also yaks that make any of those faster are always good too. Shaving a few minutes of something you run multiple times a day is always worth it.
@testobsessed If I have users I tend to shave yaks related to whether I can see what is going on and debug user problems. This can be observability as conventionally defined, but can also be things like admin web pages.
@testobsessed Thanks for mentioning vips, which I didn't know about but looks pretty handy: https://github.com/libvips/libvips
GitHub - libvips/libvips: A fast image processing library with low memory needs.

A fast image processing library with low memory needs. - libvips/libvips

GitHub
@testobsessed it's kind of surprising that OTel could produce errors. It has a very clear design goal that no matter what, it shouldn't make things worse.
@jenniferplusplus I didn't dive into the errors since I knew that I had done exactly 0 to make it work locally. I am quite sure it's not OTel's fault, and is probably as simple as not having my creds for Honeycomb set up locally.
@testobsessed always a good idea to have a .node-version file or a .nvmrc which tells you which version to install (I'd recommend brew uninstall node && brew install fnm, and then fnm use 16 after added it to your shell settings)
@thisismissem Oooh great tip! Yes, I will do that. Thank you!
@testobsessed fwiw, fnm is like nvm, but written in Rust and super fast, and includes stuff like auto-switching the version based on directory

@testobsessed Glad you figured it out. When I got to yak 4, my first thought was "no, don't upgrade local, check what version worked in CI" I fully expected it to be a CI dependency on a down level version.

Thanks for the surprise twist ending. But your point remains equally valid.

My yaks are smaller. Sumo query works, sent alert to slack this morning. Duplicate, with mods, to diff slack channel, now neither one sends webhook, while both correctly alert in Sumo. ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

@pseudonym As it happens, I spent 2 hours the other day banging my head against that particular mysterious error, so I knew it was a node version issue, and that my local environment was wrong. What I *don't* know is how my local environment reverted to using the wrong node version. πŸ€·β€β™€οΈ