vault/.hooks/pre-commit

79 lines
2.6 KiB
Text
Raw Normal View History

#!/usr/bin/env bash
# READ THIS BEFORE MAKING CHANGES:
#
# If you want to add a new pre-commit check, here are the rules:
#
# 1. Create a bash function for your check (see e.g. ui_lint below).
# NOTE: Each function will be called in a sub-shell so you can freely
# change directory without worrying about interference.
# 2. Add the name of the function to the CHECKS variable.
# 3. If no changes relevant to your new check are staged, then
# do not output anything at all - this would be annoying noise.
# In this case, call 'return 0' from your check function to return
# early without blocking the commit.
# 4. If any non-trivial check-specific thing has to be invoked,
# then output '==> [check description]' as the first line of
# output. Each sub-check should output '--> [subcheck description]'
# after it has run, indicating success or failure.
# 5. Call 'block [reason]' to block the commit. This ensures the last
# line of output calls out that the commit was blocked - which may not
# be obvious from random error messages generated in 4.
#
# At the moment, there are no automated tests for this hook, so please run it
# locally to check you have not broken anything - breaking this will interfere
# with other peoples' workflows significantly, so be sure, check everything twice.
set -euo pipefail
# Call block to block the commit with a message.
block() {
echo "$@"
echo "Commit blocked - see errors above."
exit 1
}
# Add all check functions to this space separated list.
# They are executed in this order (see end of file).
CHECKS="ui_lint backend_lint"
# Run ui linter if changes in that dir detected.
ui_lint() {
local DIR=ui LINTER=node_modules/.bin/lint-staged
# Silently succeed if no changes staged for $DIR
if git diff --name-only --cached --exit-code -- $DIR/; then
return 0
fi
# Silently succeed if the linter has not been installed.
# We assume that if you're doing UI dev, you will have installed the linter
# by running yarn.
if [ ! -x $DIR/$LINTER ]; then
return 0
fi
echo "==> Changes detected in $DIR/: Running linter..."
# Run the linter from the UI dir.
cd $DIR
$LINTER || block "UI lint failed"
}
backend_lint() {
# Silently succeed if no changes staged for Go code files.
staged=$(git diff --name-only --cached --exit-code -- '*.go')
ret=$?
if [ $ret -eq 0 ]; then
return 0
fi
[QT-645] Restructure dev tools (#24559) We're on a quest to reduce our pipeline execution time to both enhance our developer productivity but also to reduce the overall cost of the CI pipeline. The strategy we use here reduces workflow execution time and network I/O cost by reducing our module cache size and using binary external tools when possible. We no longer download modules and build many of the external tools thousands of times a day. Our previous process of installing internal and external developer tools was scattered and inconsistent. Some tools were installed via `go generate -tags tools ./tools/...`, others via various `make` targets, and some only in Github Actions workflows. This process led to some undesirable side effects: * The modules of some dev and test tools were included with those of the Vault project. This leads to us having to manage our own Go modules with those of external tools. Prior to Go 1.16 this was the recommended way to handle external tools, but now `go install tool@version` is the recommended way to handle external tools that need to be build from source as it supports specific versions but does not modify the go.mod. * Due to Github cache constraints we combine our build and test Go module caches together, but having our developer tools as deps in our module results in a larger cache which is downloaded on every build and test workflow runner. Removing the external tools that were included in our go.mod reduced the expanded module cache by size by ~300MB, thus saving time and network I/O costs when downloading the module cache. * Not all of our developer tools were included in our modules. Some were being installed with `go install` or `go run`, so they didn't take advantage of a single module cache. This resulted in us downloading Go modules on every CI and Build runner in order to build our external tools. * Building our developer tools from source in CI is slow. Where possible we can prefer to use pre-built binaries in CI workflows. No more module download or tool compiles if we can avoid them. I've refactored how we define internal and external build tools in our Makefile and added several new targets to handle both building the developer tools locally for development and verifying that they are available. This allows for an easy developer bootstrap while also supporting installation of many of the external developer tools from pre-build binaries in CI. This reduces our network IO and run time across nearly all of our actions runners. While working on this I caught and resolved a few unrelated issue: * Both our Go and Proto format checks we're being run incorrectly. In CI they we're writing changes but not failing if changes were detected. The Go was less of a problem as we have git hooks that are intended to enforce formatting, however we drifted over time. * Our Git hooks couldn't handle removing a Go file without failing. I moved the diff check into the new Go helper and updated it to handle removing files. * I combined a few separate scripts and into helpers and added a few new capabilities. * I refactored how we install Go modules to make it easier to download and tidy all of the projects go.mod's. * Refactor our internal and external tool installation and verification into a tools.sh helper. * Combined more complex Go verification into `scripts/go-helper.sh` and utilize it in the `Makefile` and git commit hooks. * Add `Makefile` targets for executing our various tools.sh helpers. * Update our existing `make` targets to use new tool targets. * Normalize our various scripts and targets output to have a consistent output format. * In CI, install many of our external dependencies as binaries wherever possible. When not possible we'll build them from scratch but not mess with the shared module cache. * [QT-641] Remove our external build tools from our project Go modules. * [QT-641] Remove extraneous `go list`'s from our `set-up-to` composite action. * Fix formatting and regen our protos Signed-off-by: Ryan Cragun <me@ryan.ec>
2024-01-09 12:50:46 -05:00
# Only run check-fmt on staged files
./scripts/go-helper.sh check-fmt "${staged}" || block "Backend linting failed; run 'make fmt' to fix."
}
for CHECK in $CHECKS; do
# Force each check into a subshell to avoid crosstalk.
( $CHECK ) || exit $?
done