… but cd is a built-in

I highly recommend installing fzf, and its shell integration. Makes your Ctrl + r magnitudes more pleasant to use!

This is up there with left-pad now!

I can’t believe they didn’t with go with BatShIt. it’s right there! they were SO close!

I just started using this at $jorb. Check out their “ui-mode” is all I’m going to say about that.

I’ll take it over QuickTime

The sentiment of the first half of your comment is the cause of the problem you describe in the second half. Why /should/ the CI tool have any “steps” built in? Use a task runner, or script in your repo for any task you expect CI to do. Configure CI to run the same command you would run locally.

like this?

it’s awful and I hate it. I generally prefer not to have a shared identity across communities, and there’s no way to create a usable discord identity without a phone number.

It might be an attention thing. With an emoji in a post your eyes are drawn towards the cute colorful picture before you l’ve read the content of the post. Emoticons on the other hand don’t stand out as much, but serve a similar purpose: punctuate a thought with an emotion (=

I can see it happening if it becomes an “appliance”, similar market to what the home assistant green doodad is going for. “put this shiny blue cube full of hard drives into your kitchen, and join the identiverse! it also comes in purple!”

My point is, having PRs desn’t result in perfect code either. They might help sometimes, maybe 10% of the time if I’m being generous, but the rest of the time they are a hindrance. The problems people tend to try and solve with them, validation and indoctrination are better solved with a good CD pipeline, and pairing sessions.

If your team consists of people you don’t trust, that’s the problem to fix first.

The solution to that is pairing - spending a few hours collaborating with, and teaching this person will get them up to speed much faster than asynchronously nitpicking their code.

Mandatory pull requests + approvals within a team are a waste of everyone’s time.

I would recommend you avoid relying on features of GitHub, and only use features of git. You never know when you might decide to switch repo hosting providers!

With that said, you’ve got a number of options: you can use tags or branches as “labels” to choose what’s applied to what environment, or depending on the flavor of IaC you’re using, have an entry point for each environment in your code which includes and parameterizes a common “environment” module.