start checking some third party builds for regressions
Our tests should already be pretty extensive, and any bug fixes should result in more regression test cases, but testing against a few diverse and popular third party modules will help prevent unintended regressions while developing garble. The list is short for now. More can be added later. This adds protobuf and wireguard from the original issue, but not cobra and logrus, as they aren't particularly complex nor add significant variety on top of protobuf and wireguard. While here, we remove the job that only runs crlf-test.sh, as we don't really need a separate job for a tiny script. Fixes #240.pull/540/head
parent
7fb390e403
commit
201d890430
@ -0,0 +1,8 @@
|
||||
module test
|
||||
|
||||
go 1.18
|
||||
|
||||
require (
|
||||
github.com/samber/lo v1.21.0 // indirect
|
||||
golang.org/x/exp v0.0.0-20220303212507-bbda1eaf7a17 // indirect
|
||||
)
|
@ -0,0 +1,4 @@
|
||||
github.com/samber/lo v1.21.0 h1:FSby8pJQtX4KmyddTCCGhc3JvnnIVrDA+NW37rG+7G8=
|
||||
github.com/samber/lo v1.21.0/go.mod h1:2I7tgIv8Q1SG2xEIkRq0F2i2zgxVpnyPOP0d3Gj2r+A=
|
||||
golang.org/x/exp v0.0.0-20220303212507-bbda1eaf7a17 h1:3MTrJm4PyNL9NBqvYDSj3DHl46qQakyfqfWo4jgfaEM=
|
||||
golang.org/x/exp v0.0.0-20220303212507-bbda1eaf7a17/go.mod h1:lgLbSvA5ygNOMpwM/9anMpWVlVJ7Z+cHWq/eFuinpGE=
|
@ -0,0 +1,11 @@
|
||||
module test
|
||||
|
||||
go 1.18
|
||||
|
||||
require (
|
||||
golang.org/x/crypto v0.0.0-20220315160706-3147a52a75dd // indirect
|
||||
golang.org/x/net v0.0.0-20220225172249-27dd8689420f // indirect
|
||||
golang.org/x/sys v0.0.0-20220315194320-039c03cc5b86 // indirect
|
||||
golang.zx2c4.com/wintun v0.0.0-20211104114900-415007cec224 // indirect
|
||||
golang.zx2c4.com/wireguard v0.0.0-20220317033214-ee1c8e0e8789 // indirect
|
||||
)
|
@ -0,0 +1,10 @@
|
||||
golang.org/x/crypto v0.0.0-20220315160706-3147a52a75dd h1:XcWmESyNjXJMLahc3mqVQJcgSTDxFxhETVlfk9uGc38=
|
||||
golang.org/x/crypto v0.0.0-20220315160706-3147a52a75dd/go.mod h1:IxCIyHEi3zRg3s0A5j5BB6A9Jmi73HwBIUl50j+osU4=
|
||||
golang.org/x/net v0.0.0-20220225172249-27dd8689420f h1:oA4XRj0qtSt8Yo1Zms0CUlsT3KG69V2UGQWPBxujDmc=
|
||||
golang.org/x/net v0.0.0-20220225172249-27dd8689420f/go.mod h1:CfG3xpIq0wQ8r1q4Su4UZFWDARRcnwPjda9FqA0JpMk=
|
||||
golang.org/x/sys v0.0.0-20220315194320-039c03cc5b86 h1:A9i04dxx7Cribqbs8jf3FQLogkL/CV2YN7hj9KWJCkc=
|
||||
golang.org/x/sys v0.0.0-20220315194320-039c03cc5b86/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
|
||||
golang.zx2c4.com/wintun v0.0.0-20211104114900-415007cec224 h1:Ug9qvr1myri/zFN6xL17LSCBGFDnphBBhzmILHsM5TY=
|
||||
golang.zx2c4.com/wintun v0.0.0-20211104114900-415007cec224/go.mod h1:deeaetjYA+DHMHg+sMSMI58GrEteJUUzzw7en6TJQcI=
|
||||
golang.zx2c4.com/wireguard v0.0.0-20220317033214-ee1c8e0e8789 h1:VOTlV0x4S7exvgtanezUuF/s++xx6ZHrPZRi8dEW7dM=
|
||||
golang.zx2c4.com/wireguard v0.0.0-20220317033214-ee1c8e0e8789/go.mod h1:bVQfyl2sCM/QIIGHpWbFGfHPuDvqnCNkT6MQLTCjO/U=
|
@ -0,0 +1,78 @@
|
||||
#!/bin/bash
|
||||
|
||||
# List of popular modules which we use as regression tests.
|
||||
# Right now we only "garble build" them, but eventually it would be nice to use
|
||||
# "garble test" with them as well, assuming they have good tests.
|
||||
#
|
||||
# The criteria to add modules to this list is that they should be:
|
||||
#
|
||||
# * Popular; likely to be used in Go projects built with Garble
|
||||
# * Good quality; avoid projects with tons of generated code or slow tests
|
||||
# * Diverse; avoid multiple projects which are extremely similar
|
||||
#
|
||||
# For example, a good example of a project to add is one that has unearthed
|
||||
# multiple bugs in garble before, such as Protobuf.
|
||||
# Also remember that the standard library already provides significant cover.
|
||||
modules=(
|
||||
# Protobuf helps cover encoding libraries and reflection.
|
||||
# TODO: currently fails.
|
||||
# google.golang.org/protobuf v1.28.0
|
||||
|
||||
# Wireguard helps cover networking and cryptography.
|
||||
golang.zx2c4.com/wireguard 0.0.20220316
|
||||
|
||||
# Lo helps cover generics.
|
||||
# TODO: would be nice to find a more popular alternative,
|
||||
# at least once generics are more widespread.
|
||||
github.com/samber/lo v1.21.0
|
||||
|
||||
# TODO: consider a SQL driver like modernc.org/sqlite
|
||||
)
|
||||
|
||||
SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )
|
||||
|
||||
export GOGARBLE="*"
|
||||
|
||||
exit_code=0
|
||||
|
||||
show() {
|
||||
echo "> ${@}"
|
||||
"${@}"
|
||||
}
|
||||
|
||||
BASE_GOFLAGS="$(go env GOFLAGS)"
|
||||
CACHED_MODFILES="${SCRIPT_DIR}/cached_modfiles"
|
||||
mkdir -p "${CACHED_MODFILES}"
|
||||
|
||||
for (( i=0; i<${#modules[@]}; i+=2 )); do
|
||||
module="${modules[i]}"
|
||||
version="${modules[i+1]}"
|
||||
|
||||
{
|
||||
# Initialize an empty module, so we can run "go build",
|
||||
# and add the module at the version that we want.
|
||||
# We cache the files between runs and commit them in git,
|
||||
# because each "go get module/...@version" is slow as it has to figure
|
||||
# out where the module lives, even if GOMODCACHE is populated.
|
||||
cached_modfile="${module}_${version}"
|
||||
cached_modfile="${CACHED_MODFILES}/${cached_modfile//[^A-Za-z0-9._-]/_}.mod"
|
||||
if [[ ! -f "${cached_modfile}" ]]; then
|
||||
show go mod init test
|
||||
show go get "${module}/...@${version}"
|
||||
fi
|
||||
|
||||
# Use the custom go.mod file for the rest of the commands.
|
||||
export GOFLAGS="${BASE_GOFLAGS} -modfile=${cached_modfile}"
|
||||
|
||||
# Run "go build" first, to ensure the regular Go build works.
|
||||
show go build "${module}/..."
|
||||
|
||||
# Run the garble build.
|
||||
show garble build "${module}/..."
|
||||
|
||||
# Also with more options.
|
||||
show garble -tiny -literals build "${module}/..."
|
||||
} || exit_code=1
|
||||
done
|
||||
|
||||
exit ${exit_code}
|
Loading…
Reference in New Issue