Apply 50min timeout to integration tests

IMHO, longer than this waiting for automated testing is "too long".

Scientificaly speaking, based on thousands of runs across many
platforms, successful runs always happen in less time.  Normally
Ubuntu passes in 35-40 minutes, and the Fedoras do it in 25-30.

If they take longer, something is likely badly broken.  In that
case, it's better to fail within a short/defined time, than wait
for the (much longer) automation-level timeout and inevitable
failure.

Signed-off-by: Chris Evich <cevich@redhat.com>
This commit is contained in:
Chris Evich
2019-02-05 13:22:42 -05:00
parent 3554bfce98
commit ede38d3600

View File

@ -41,6 +41,10 @@ ISODATE ?= $(shell date --iso-8601)
#Update to LIBSECCOMP_COMMIT should reflect in Dockerfile too.
LIBSECCOMP_COMMIT := release-2.3
# Rarely if ever should integration tests take more than 50min,
# caller may override in special circumstances if needed.
GINKGOTIMEOUT ?= -timeout=50m
# If GOPATH not specified, use one in the local directory
ifeq ($(GOPATH),)
export GOPATH := $(CURDIR)/_output
@ -170,10 +174,10 @@ localunit: test/goecho/goecho varlink_generate
$(MAKE) -C contrib/cirrus/packer test
ginkgo:
ginkgo -v -tags "$(BUILDTAGS)" -cover -flakeAttempts 3 -progress -trace -noColor test/e2e/.
ginkgo -v -tags "$(BUILDTAGS)" $(GINKGOTIMEOUT) -cover -flakeAttempts 3 -progress -trace -noColor test/e2e/.
ginkgo-remote:
ginkgo -v -tags "$(BUILDTAGS) remoteclient" -cover -flakeAttempts 3 -progress -trace -noColor test/e2e/.
ginkgo -v -tags "$(BUILDTAGS) remoteclient" $(GINKGOTIMEOUT) -cover -flakeAttempts 3 -progress -trace -noColor test/e2e/.
localintegration: varlink_generate test-binaries ginkgo ginkgo-remote