From patchwork Tue Feb 20 03:27:14 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luke Shumaker X-Patchwork-Id: 422 Return-Path: Delivered-To: patchwork@archlinux.org Received: from apollo.archlinux.org (localhost [127.0.0.1]) by apollo.archlinux.org (Postfix) with ESMTP id 9180222055C6 for ; Tue, 20 Feb 2018 03:27:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on apollo.archlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED=-2.3 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-BL-Results: [127.0.9.2] Received: from orion.archlinux.org (orion.archlinux.org [IPv6:2a01:4f8:160:6087::1]) by apollo.archlinux.org (Postfix) with ESMTPS for ; Tue, 20 Feb 2018 03:27:37 +0000 (UTC) Received: from orion.archlinux.org (localhost [127.0.0.1]) by orion.archlinux.org (Postfix) with ESMTP id CC3648D311F97; Tue, 20 Feb 2018 03:27:30 +0000 (UTC) Received: from luna.archlinux.org (luna.archlinux.org [5.9.250.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by orion.archlinux.org (Postfix) with ESMTPS; Tue, 20 Feb 2018 03:27:30 +0000 (UTC) Received: from luna.archlinux.org (luna.archlinux.org [127.0.0.1]) by luna.archlinux.org (Postfix) with ESMTP id AA8272D473; Tue, 20 Feb 2018 03:27:30 +0000 (UTC) Authentication-Results: luna.archlinux.org; dkim=none Received: from luna.archlinux.org (luna.archlinux.org [127.0.0.1]) by luna.archlinux.org (Postfix) with ESMTP id 79A8520880 for ; Tue, 20 Feb 2018 03:27:28 +0000 (UTC) Received: from orion.archlinux.org (orion.archlinux.org [IPv6:2a01:4f8:160:6087::1]) by luna.archlinux.org (Postfix) with ESMTPS for ; Tue, 20 Feb 2018 03:27:28 +0000 (UTC) Received: from orion.archlinux.org (localhost [127.0.0.1]) by orion.archlinux.org (Postfix) with ESMTP id 5AC828D311F8B for ; Tue, 20 Feb 2018 03:27:21 +0000 (UTC) Received: from mav.lukeshu.com (mav.lukeshu.com [104.207.138.63]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by orion.archlinux.org (Postfix) with ESMTPS for ; Tue, 20 Feb 2018 03:27:16 +0000 (UTC) Received: from build64-par (unknown [IPv6:2601:803:202:9275:da50:e6ff:fe00:4a5b]) by mav.lukeshu.com (Postfix) with ESMTPSA id 0426980502 for ; Mon, 19 Feb 2018 22:27:14 -0500 (EST) From: Luke Shumaker To: arch-projects@archlinux.org Date: Mon, 19 Feb 2018 22:27:14 -0500 Message-Id: <20180220032714.2738-1-lukeshu@lukeshu.com> X-Mailer: git-send-email 2.16.1 Subject: [arch-projects] [dbscripts] [PATCH v4] test: db-update: verify that PKGEXT(S) is treated as a glob X-BeenThere: arch-projects@archlinux.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Arch Linux projects development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Arch Linux projects development discussion Errors-To: arch-projects-bounces@archlinux.org Sender: "arch-projects" From: Luke Shumaker 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}