… 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.

I’ve had it happen on servers where that moderation option is not enabled. My worst experience was trying to join a friend group’s discord via an invite link shared with me. I was prompted to create an account with email, and I did. I was then shown a read-only view of the server: I could see all messages and other folks could see I joined and 👋 to me. I could not send messages myself, however, without verifying with a phone number. Further, I couldn’t use a Google voice number (my primary number) to verify, nor my “real” number which was associated to another account.

Sometimes it depends on discord itself finding you suspicious, for some definition of suspicious. perhaps a user agent whitelist? lack of Google cookie?

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.

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 agree. What I’m proposing is, if you go with that option, that you use a branch as a “single instance label”, pointing at commits within your main branch. Don’t use them as actual branches for additional environment-specific commits.

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.