RandomDevOpsDude

I believe in GitHub branch protection rules, you can set required review by a code owner, as well as set an amount of reviews required.

You are also able to structure codeowner files and assign codeowners to certain paths within the repo that they "own", rather than all or nothing.

You are able to set bypass rules for certain individuals, and as repo admin there is a little checkbox on PRs that will appear by default to allow you to ignore the requirements, although it is generally not recommended, but I won't harp on the reasons others have already pointed out.

disclaimer: I mainly work on a GHES instance, which may be function slightly different than public GH

I think JetBrains has fully bought into Gradle. I think Maven support has been less and less over time, which shouldn't be a surprise. Gradle supports native Kotlin build scripts (i.e. build.gradle.kts), as well as putting a lot of work into ensuring their tools fit well within the Gradle ecosystem (exhibit A: https://github.com/JetBrains/intellij-platform-plugin-template). I think it only natural for the creator/owner/maintainer of Kotlin to go full in on the build system that supports the language!

controversial take: who still uses maven? who would prefer xml files over build scripts? (ok... fine, big timers like RedHat definitely do, or at least, have never taken/don't want to take the time to upgrade lol)

I'm not big on Samsung devices outside TVs/monitors (although expensive, definitely best quality IMO). However, I am a fan of them leaning toward affordability to the average consumer! Assuming able to root, remove Tizen, and install from custom ROM, I may look into getting one of these now.

December 8th, 2009 - Motorola Droid successfully rooted ... [granting] root access on the phone using a terminal emulator. This is how I learned bash which inevitably pushed me into pursuing proper Computer Science.

wiki ref

I prefer a similar workflow.

I am a major advocate of keeping CI as simple as possible, and letting build tools do the job they were built to do. Basic builds and unit/component testing. No need for overcomplicating things for the sake of "doing it all in one place".

CD is where things get dirty, and it really depends on how/what/where you are deploying.

Generally speaking, if integration testing with external systems is necessary, I like to have contract testing with these systems done during CI, then integration/e2e in an environment that mimics production (bonus points if ephemeral).

The most difficult generalisation step is going from one to two. Once you've generalised to two cases, it's much easier to generalise to three, four, or n cases.

🥇

Although it seems to ignore things like sidecar containers to support the application locally (rather than needing to do a full install of a database tech, for example), I really like the point being driven.

SRE is the Ops part of DevOps, if you ask me.

I made a detailed comment recently about SRE.

I personally agree that it makes sense to use !devops for SRE related content.

I think Go is good to learn. Many vetted open source Go tooIs use Makefiles (e.g. kustomize) which may be a good point of entry for DevOps in Go.

Just make sure to test the regex instead of blindly slapping it in assuming it works 🙂

It covers each and every line of the source code, each and every conditional statement in the program and every loop otherwise known as iteration in the program.

I think it is important to note 100% code coverage ("covers each and every line") does not mean the tests are good tests.

The myth of 100% code coverage

Yes, I write SpringBoot microservices and IntelliJ plugins using Kotlin. Any new code is Kotlin, but there is still a ton of Java, which I don't consider "legacy", since it works, and if I can sanely add Kotlin when necessary, I don't see the need for "full rewrite".

You may get more traction by asking the Kotlin community

I did not know this, thank you for sharing. I am going to leave the comment because it has generated some good discourse (and hopefully maybe more) and in my reality, I don't think I would even notice if this instance chooses defederation.