mirror of
https://github.com/optim-enterprises-bv/vault.git
synced 2025-10-29 17:52:32 +00:00
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>
79 lines
2.6 KiB
Bash
Executable File
79 lines
2.6 KiB
Bash
Executable File
#!/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
|
|
|
|
# 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
|