[arch-projects] [dbscripts] [PATCH v4] test: db-update: verify that PKGEXT(S) is treated as a glob

[Luke Shumaker]

From: Luke Shumaker <lukeshu at parabola.nu>

Commit b61a714 introduced a regression that in a db-functions function
called by db-update, config:PKGEXT is treated like a fixed string, instead
of as a glob.  Because of inadequacy of the test-suite, this did not cause
a test failure.

https://lists.archlinux.org/pipermail/arch-projects/2018-February/004742.html

The broken function checks if the repo already contains a package that
matches the one being released.  This did not trigger a test-suite failure
because right after the broken check there is another check that checks for
the exact filename of the new package file.  In the test-suite, all
package files have the same extension, so the latter check always "saved"
us.

So, modify a relevant test case (a test case that verifies that we can't
release the same package twice) such that the second time we release the
package, we set PKGEXT to something different (.gz, instead of the normal
.xz).  This way, we can be sure that when db-update rejects the operation,
it's because of the glob check, not the exact-filename check.

This is made slightly tricky because the __buildPackage() test helper
routine tries to cache builds, to speed up the tests.  Without
modification, this means that it will just ignore the new PKGEXT.  So,
modify it to only use the cache if it can successfully copy build artifacts
out, in a way that respects PKGEXT.

v2:
 - Follow Eli's suggestion to simplify the test-case by modifying
   __buildPackage so that the test-case itself doesn't need to worry about
   the call being cached.
v3:
 - Simplify the test-case further by having it not prune the cache after
   running.
v4:
 - Follow Eli's suggestion of simplifying __buildPackage by having the copy
   operation itself be the test on whether to use the cache.
 - Improve the commit message.
---
I've also submitted this as a GitHub PR.
https://github.com/archlinux/dbscripts/pull/3

You can verify that applying this without Eli's fix patchset it causes
a test failure, but with Eli's fix patchset the tests pass.

 test/cases/db-update.bats | 2 +-
 test/lib/common.bash      | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/test/cases/db-update.bats b/test/cases/db-update.bats
index 1da7eef..2395438 100644
--- a/test/cases/db-update.bats
+++ b/test/cases/db-update.bats
@@ -92,7 +92,7 @@ load ../lib/common
 	db-update
 	checkPackage extra pkg-any-a
 
-	releasePackage extra pkg-any-a
+	PKGEXT=.pkg.tar.gz releasePackage extra pkg-any-a
 	run db-update
 	[ "$status" -ne 0 ]
 }
diff --git a/test/lib/common.bash b/test/lib/common.bash
index 540e403..e9cf6c9 100644
--- a/test/lib/common.bash
+++ b/test/lib/common.bash
@@ -23,8 +23,7 @@ __buildPackage() {
 
 	if [[ -n ${BUILDDIR} ]]; then
 		cache=${BUILDDIR}/$(__getCheckSum PKGBUILD)
-		if [[ -d ${cache} ]]; then
-			cp -Lv ${cache}/*${PKGEXT}{,.sig} ${pkgdest}
+		if cp -Lv ${cache}/*${PKGEXT}{,.sig} ${pkgdest} 2>/dev/null; then
 			return 0
 		else
 			mkdir -p ${cache}
-- 
2.16.1