verify-conformance-release

The behaviour of the bot is described here, in Gherkin. Each scenario is a requirement a PR must meet to qualify for conformance.

Note: the line immediately beneath the scenario is the comment posted to the PR if the requirement is not met.

See the feature scenarios, in ./kodata/features.

Build locally

ko build --local -B --tags latest .

Set up local dev

Log into GitHub regularly

unset GITHUB_TOKEN
gh auth login

Update the oauth secret

kubectl -n prow create secret generic prow-github-oauth \
    --from-literal=oauth=$(yq e '."github.com".oauth_token' -P - < ~/.config/gh/hosts.yml) \
    --dry-run=client -o yaml \
    | kubectl apply -f -

Install the config

kubectl -n prow create cm vcr-config --from-file=vcr.yaml=./hack/vcr.yaml --dry-run=client -o yaml | \
    kubectl -n prow apply -f -

Install the plugin

ko apply --local -B -f ./hack/verify-conformance-release-deployment-dev-temp.yaml -- -n prow

Read the logs

kubectl -n prow logs -l app=verify-conformance-release --tail=50 -f

Restart it

kubectl -n prow rollout restart deployment verify-conformance-release

Uninstall the plugin

kubectl -n prow delete -f ./hack/verify-conformance-release-deployment-dev-temp.yaml

Run trial-implementation

cd ./cmd/trial-implementation
go run .

Running the plugin locally

When run locally the plugin interacts with GitHub but by default does not make any changes if you want to apply changes to the PR inspected then you can pass in the flag, dry-run=false

./verify-conformance-release --hmac-secret-file=/home/ii/.secret-hook --github-token-path=/home/ii/.secret-oauth --plugin-config=./hack/vcr.yaml