kuritka

This checklist is consolidated from Tim Hawkin's "How To Be A Bad-Ass Code Reviewer" (KubeCon Contributor Summit, Nov 2019).

Out of scope: API review, KEP review

• Pre-work
  • Do I have enough time for this review?
  • Read linked issues
  • Read PR description
  • Read over past discussions
• Does this change require domain specific knowledge? Do I have it?

kuritka

package test

import (
	"github.com/stretchr/testify/require"
	"k8gbterratest/utils"
	"testing"
)

func TestMyDemo(t *testing.T) {
	const host= "terratest-failover.cloud.example.com"

kuritka

Short prometheus DEMO

# running in context of k3d-test-gslb2
# waiting...
make stop-testapp
# waiting
make start-testapp

kuritka

I invested a little time today in something like this:

SHELL := /bin/bash

init=@./make-tools --init -m "starting"
save=@./make-tools --message "saving value" --save
load=@./make-tools --debug --load
exists=@./make-tools -m "environment variable doesn't exist" --env-exists
# Options

kuritka

preventing commit having sensitive information in commit message

Sometimes it happens that people accidentally push information from inside the organization to the public github repository. It could be hostname, ip address, proxy etc... This information could be somewhere in commit mesage and if reviewers see it, it's too late.

For this reason, I created a GitHook protection (short snippet running locally in your project) that warns you if it finds vulnerable information before you commit.

See the vulnerable commit message

Vulnerable commit