lunny/git-lfs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
74c51fa885
git-lfs/script/cibuild

56 lines
1.5 KiB
Plaintext
Raw Normal View History

update the shebang lines to use bash
2015-07-30 02:37:31 +00:00
#!/usr/bin/env bash
fail fast if script/test fails
2015-05-19 01:15:16 +00:00
set -e
script/cibuild: :nail_care:
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.
script/cibuild: don't filter out GIT_DEFAULT_HASH While we don't currently have access to a version of Git that supports SHA-256, one will soon be available, and we'll need to support those versions. To make sure our test suite works properly, we'll need to run a test with SHA-256, so let's allow passing the GIT_DEFAULT_HASH environment variable into our CI job script.
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
script/cibuild: :nail_care:
2018-07-24 19:35:05 +00:00
fi
script/cibuild: check for code formatting Sometimes we get contributions from folks who aren't very familiar with Go. This is great, but since they aren't familiar with Go, they don't know to use go fmt or goimports to tidy files. This leads to files that are misformatted, which then causes problems when users who do have these tools are doing development. Let's help people check formatting automatically by running it as part of the CI job. We already check for trailing whitespace, which is complementary (since it looks at non-Go files as well), and that check has been effective, so likely this one will be as well. There is one potential downside: sometimes output changes between versions of Go. This is unfortunate, but we'll need to just pin to whatever version GitHub Actions uses.
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
don't pass GIT_TRACE to exec.Command calls in the git package
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
don't pass GIT_TRACE to exec.Command calls in the git package
2016-02-03 19:06:23 +00:00
*: run tests under prove on CI
2018-07-11 18:58:19 +00:00
pushd t >/dev/null
appveyor.yml: ensure tests are functional on Windows
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
appveyor.yml: ensure tests are functional on Windows
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"
*: run tests under prove on CI
2018-07-11 18:58:19 +00:00
popd >/dev/null
script: check for trailing whitespace as part of CI Since we'd like to avoid trailing whitespace in our codebase, help developers catch issues by checking for trailing whitespace during CI. Exclude the vendor directory, as we don't want to change vendored code, and exclude any git objects or indices we store in the repository, since they're binary zlib-compressed data. Exclude batch files as well, since they contain carriage returns, which are considered non-linefeed whitespace on Unix. Note that we use git grep -E, since not all versions of git grep are compiled with PCRE for the -P option. Fortunately, POSIX provides a character class that matches all whitespace.
2018-10-03 20:40:53 +00:00
echo "Looking for trailing whitespace..."
script/cibuild: make trailing whitespace check fatal We currently intend for our CI check for trailing whitespace to be fatal; that is, if any trailing whitespace is present, our CI script should fail. However, currently that doesn't work, since apparently set -e is not concerned with a negated pipeline having a nonzero exit code. To make things more robust, let's make this into an if statement and exit 1 if we match any files (that is, if grep returns 0). Note that this used to work because it was the last command in the file, but it no longer does for the above reason.
2020-07-24 16:53:18 +00:00
if git grep -lE '[[:space:]]+$' | \
grep -vE '(^vendor/|\.git/(objects/|index)|\.bat$)'
then
exit 1
fi
script/cibuild: check for code formatting Sometimes we get contributions from folks who aren't very familiar with Go. This is great, but since they aren't familiar with Go, they don't know to use go fmt or goimports to tidy files. This leads to files that are misformatted, which then causes problems when users who do have these tools are doing development. Let's help people check formatting automatically by running it as part of the CI job. We already check for trailing whitespace, which is complementary (since it looks at non-Go files as well), and that check has been effective, so likely this one will be as well. There is one potential downside: sometimes output changes between versions of Go. This is unfortunate, but we'll need to just pin to whatever version GitHub Actions uses.
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)" ]
Reference in New Issue Copy Permalink