2015-07-30 02:37:31 +00:00
|
|
|
#!/usr/bin/env bash
|
2015-05-19 01:15:16 +00:00
|
|
|
set -e
|
2018-07-24 19:35:05 +00:00
|
|
|
|
Switch CI to use GitHub Actions
Currently, we have three different CI systems that handle our CI: Travis
for Linux, CircleCI for macOS, and AppVeyor for Windows. This results
in widely varying performance across systems and the need to maintain
code that works differently across different CI systems.
In addition, we'd like to use GitHub Actions to automate the release
process, so it makes sense to use it for CI as well. Switch over by
adding a CI workflow that runs our existing jobs. Ensure that we filter
out the environment variables that GitHub Actions provides, since they
will cause tests that run "git lfs env" to fail.
Add a script for those jobs where we build a custom Git and install the
appropriate dependencies. In the cibuild script, hoist the Windows
handling to the top, set a specific environment variable for us to
remember that we're on Windows, and then disable locking, which fails on
Windows and causes the testsuite to abort. These same environment
variables were set for AppVeyor and are also needed on Windows
development systems.
2019-08-09 19:07:56 +00:00
|
|
|
# Strip out CI environment variables which cause tests to fail.
|
2020-06-30 15:18:16 +00:00
|
|
|
unset $(env | grep -E '^GIT(HUB)?_' | grep -v '^GIT_DEFAULT_HASH=' | sed -e 's/=.*$//')
|
Switch CI to use GitHub Actions
Currently, we have three different CI systems that handle our CI: Travis
for Linux, CircleCI for macOS, and AppVeyor for Windows. This results
in widely varying performance across systems and the need to maintain
code that works differently across different CI systems.
In addition, we'd like to use GitHub Actions to automate the release
process, so it makes sense to use it for CI as well. Switch over by
adding a CI workflow that runs our existing jobs. Ensure that we filter
out the environment variables that GitHub Actions provides, since they
will cause tests that run "git lfs env" to fail.
Add a script for those jobs where we build a custom Git and install the
appropriate dependencies. In the cibuild script, hoist the Windows
handling to the top, set a specific environment variable for us to
remember that we're on Windows, and then disable locking, which fails on
Windows and causes the testsuite to abort. These same environment
variables were set for AppVeyor and are also needed on Windows
development systems.
2019-08-09 19:07:56 +00:00
|
|
|
|
|
|
|
UNAME=$(uname -s)
|
|
|
|
X=""
|
|
|
|
if [[ $UNAME == MINGW* || $UNAME == MSYS* || $UNAME == CYGWIN* ]]; then
|
|
|
|
X=".exe"
|
|
|
|
WINDOWS=1
|
|
|
|
export GIT_LFS_NO_TEST_COUNT=1
|
|
|
|
export GIT_LFS_LOCK_ACQUIRE_DISABLED=1
|
2018-07-24 19:35:05 +00:00
|
|
|
fi
|
|
|
|
|
2021-05-14 17:56:24 +00:00
|
|
|
# Build git-lfs-transfer from scutiger.
|
|
|
|
cargo install --root t/scutiger scutiger-lfs
|
|
|
|
|
2019-10-02 14:18:52 +00:00
|
|
|
# Set GOPATH if it isn't already set.
|
|
|
|
eval "$(go env | grep GOPATH)"
|
|
|
|
go get golang.org/x/tools/cmd/goimports
|
|
|
|
|
|
|
|
GOIMPORTS="$GOPATH/bin/goimports"
|
Switch CI to use GitHub Actions
Currently, we have three different CI systems that handle our CI: Travis
for Linux, CircleCI for macOS, and AppVeyor for Windows. This results
in widely varying performance across systems and the need to maintain
code that works differently across different CI systems.
In addition, we'd like to use GitHub Actions to automate the release
process, so it makes sense to use it for CI as well. Switch over by
adding a CI workflow that runs our existing jobs. Ensure that we filter
out the environment variables that GitHub Actions provides, since they
will cause tests that run "git lfs env" to fail.
Add a script for those jobs where we build a custom Git and install the
appropriate dependencies. In the cibuild script, hoist the Windows
handling to the top, set a specific environment variable for us to
remember that we're on Windows, and then disable locking, which fails on
Windows and causes the testsuite to abort. These same environment
variables were set for AppVeyor and are also needed on Windows
development systems.
2019-08-09 19:07:56 +00:00
|
|
|
|
all: use Go Modules instead of Glide
Since we are now building on Go 1.11 (as of 074a2d4f (all: use Go 1.11
in CI, 2018-08-28)) and Go 1.11 supports Go Modules [1], let's stop
using Glide, and begin using Go Modules.
This involves a few things:
* Teach the Makefile how to build go.sum files instead of glide.lock
files.
* Teach continuous integration services to build Git LFS in a
non-$GOPATH environment, since (without setting GO111MODULE=on
explicitly, which we choose not to do), this will break compiling
Git LFS, because Go 1.11 will ignore modules present in a Go
checkout beneath $GOPATH.
* In order to do the above, let's also make sure that we are
un-setting $GOCACHE in the environment, as this causes Go to work
without modules support [2].
* Because we're no longer building in a `$GOPATH`-based location,
let's instruct the CircleCI base image to archive the new location,
too.
* Similarly, teach the RPM spec to build in a non-$GOPATH location.
* By contrast, since we use dh_golang to build git-lfs binaries on
Debian, let's wait until the upstream dh_golang package is released
with support for Go 1.11 module support explicitly. Therefore, force
GO111MODULE to be on so that we can build a copy of Git LFS whose
checkout is within a $GOPATH.
Although the go.mod versions match the glide.yaml ones, the diff
attached is large because Go Modules do not vendor `_test.go` files,
whereas Glide does.
[1]: https://golang.org/doc/go1.11#modules
[2]: `GOCACHE=on` will be deprecated in Go 1.12, so this change makes
sense for that reason, too.
Co-authored-by: brian m. carlson <bk2204@github.com>
2018-08-28 20:53:57 +00:00
|
|
|
make GOIMPORTS="$GOIMPORTS" && make GOIMPORTS="$GOIMPORTS" test
|
2016-02-03 19:06:23 +00:00
|
|
|
|
|
|
|
# re-run test to ensure GIT_TRACE output doesn't leak into the git package
|
all: use Go Modules instead of Glide
Since we are now building on Go 1.11 (as of 074a2d4f (all: use Go 1.11
in CI, 2018-08-28)) and Go 1.11 supports Go Modules [1], let's stop
using Glide, and begin using Go Modules.
This involves a few things:
* Teach the Makefile how to build go.sum files instead of glide.lock
files.
* Teach continuous integration services to build Git LFS in a
non-$GOPATH environment, since (without setting GO111MODULE=on
explicitly, which we choose not to do), this will break compiling
Git LFS, because Go 1.11 will ignore modules present in a Go
checkout beneath $GOPATH.
* In order to do the above, let's also make sure that we are
un-setting $GOCACHE in the environment, as this causes Go to work
without modules support [2].
* Because we're no longer building in a `$GOPATH`-based location,
let's instruct the CircleCI base image to archive the new location,
too.
* Similarly, teach the RPM spec to build in a non-$GOPATH location.
* By contrast, since we use dh_golang to build git-lfs binaries on
Debian, let's wait until the upstream dh_golang package is released
with support for Go 1.11 module support explicitly. Therefore, force
GO111MODULE to be on so that we can build a copy of Git LFS whose
checkout is within a $GOPATH.
Although the go.mod versions match the glide.yaml ones, the diff
attached is large because Go Modules do not vendor `_test.go` files,
whereas Glide does.
[1]: https://golang.org/doc/go1.11#modules
[2]: `GOCACHE=on` will be deprecated in Go 1.12, so this change makes
sense for that reason, too.
Co-authored-by: brian m. carlson <bk2204@github.com>
2018-08-28 20:53:57 +00:00
|
|
|
GIT_TRACE=1 make GOIMPORTS="$GOIMPORTS" PKGS=git test
|
2016-02-03 19:06:23 +00:00
|
|
|
|
2018-07-11 18:58:19 +00:00
|
|
|
pushd t >/dev/null
|
2018-07-17 18:31:38 +00:00
|
|
|
PROVE="prove"
|
|
|
|
PROVE_EXTRA_ARGS="-j9"
|
Switch CI to use GitHub Actions
Currently, we have three different CI systems that handle our CI: Travis
for Linux, CircleCI for macOS, and AppVeyor for Windows. This results
in widely varying performance across systems and the need to maintain
code that works differently across different CI systems.
In addition, we'd like to use GitHub Actions to automate the release
process, so it makes sense to use it for CI as well. Switch over by
adding a CI workflow that runs our existing jobs. Ensure that we filter
out the environment variables that GitHub Actions provides, since they
will cause tests that run "git lfs env" to fail.
Add a script for those jobs where we build a custom Git and install the
appropriate dependencies. In the cibuild script, hoist the Windows
handling to the top, set a specific environment variable for us to
remember that we're on Windows, and then disable locking, which fails on
Windows and causes the testsuite to abort. These same environment
variables were set for AppVeyor and are also needed on Windows
development systems.
2019-08-09 19:07:56 +00:00
|
|
|
if [ "$WINDOWS" ]; then
|
2018-07-17 18:31:38 +00:00
|
|
|
export PATH="/c/Strawberry/perl/bin:.:$PATH"
|
|
|
|
PROVE="prove.bat"
|
|
|
|
PROVE_EXTRA_ARGS="$PROVE_EXTRA_ARGS --exec bash"
|
|
|
|
fi
|
|
|
|
|
|
|
|
VERBOSE_LOGS=1 make X="$X" clean
|
|
|
|
VERBOSE_LOGS=1 make X="$X" PROVE="$PROVE" PROVE_EXTRA_ARGS="$PROVE_EXTRA_ARGS"
|
2018-07-11 18:58:19 +00:00
|
|
|
popd >/dev/null
|
2018-10-03 20:40:53 +00:00
|
|
|
|
|
|
|
echo "Looking for trailing whitespace..."
|
2020-07-24 16:53:18 +00:00
|
|
|
if git grep -lE '[[:space:]]+$' | \
|
|
|
|
grep -vE '(^vendor/|\.git/(objects/|index)|\.bat$)'
|
|
|
|
then
|
|
|
|
exit 1
|
|
|
|
fi
|
2019-10-02 14:18:52 +00:00
|
|
|
|
|
|
|
echo "Formatting files..."
|
|
|
|
# Building and installing goimports and goversioninfo will have modified go.mod
|
|
|
|
# and go.sum, so reset the branch before formatting.
|
|
|
|
git reset --hard
|
|
|
|
make GOIMPORTS="$GOIMPORTS" fmt
|
|
|
|
|
|
|
|
echo "Looking for files that are not formatted correctly..."
|
|
|
|
git status -s
|
|
|
|
[ -z "$(git status --porcelain)" ]
|