gopkg.in/check.v1 hasn't had any commit since Nov 2020.
That's not a immediate issue for a test-only dependency, but
because it hides access to the standard library *testing.T,
eventually it will become limiting.
Also, using the same framework for unit and integration tests
seems practical.
This is mostly a batch copy&paste job, with a fairly high risk
of unexpected breakage.
Also, I didn't take much time at all to carefully choose between
assert.* and require.*; we can tune that as failures show up.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Go 1.17 introduces a much more reasonable build constraint format, and gofmt now fails without using it.
Sadly we still need the old format as well, to support <1.17 builds.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Dependabot was apparently not picking these up (and
several haven't had a release for a long time anyway).
Also move from github.com/go-check/check to its newly
declared (and go.mod-enforced) name gopkg.in/check.v1.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
The necessary images have been manually copied over to quay. Code was
updated with centralized constants for the utilized images. Tests then
all reference the constants (in case the image locations need to change
again).
Signed-off-by: Chris Evich <cevich@redhat.com>
PREFIX should default to /usr/local according to GNU coding standards.
DESTDIR should just be used for install
This will allow us to specify
make PREFIX=/usr DESTDIR=/tmp/build/ install
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We are maintaining code to set up and run registries, including the
fairly complex setup for Atomic Registry, in the integration tests.
This is all useful for experimentation in shell, and the easiest way to
do that is to add a “test” which, after all the set up is done, simply
starts a shell.
This is gated by a build tag, so it does not affect normal test runs.
A possible alternative would be to convert all of the setup code not to
depend on check.C and testing.T, but that would be fairly cumbersome due
to how prevalent c.Logf and c.Assert are throughout the setup code.
Especially the natural replacement of c.Assert with a panic() would be
pretty ugly, and adding real error handling to all of that would make
the code noticeably longer. The build tag and copy&pasting a command
works just as well, at least for now.
(It is not conveniently possible to create a new “main program” which
manually creates a check.C and testing.T just for the purpose of running
the setup code either; check.C can be created given a testing.T, but
testing.T is only created by testing.MainStart, which does not allow us
to submit a non-test method; and testing.MainStart is excluded from the
Go compatibility promise.)
