From 658789f080d3073c6e68e63ed72661c11bac6191 Mon Sep 17 00:00:00 2001
From: Jean-Paul Calderone <exarkun@twistedmatrix.com>
Date: Mon, 22 Mar 2021 14:36:20 -0400
Subject: [PATCH] Hack our logic into the script instead
---
.gitlab-ci.yml | 5 -----
ci-tools/vulnerability-scan | 14 ++++++++++++++
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index d92b5037..1e3186bf 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -10,11 +10,6 @@ unit-tests:
vulnerability-scan:
stage: "test"
- # It would be nice to target this a bit more specifically. If we upgrade to
- # a newer GitLab (13.11?) then we can select exit codes that are allowed.
- # For now we're stuck with true/false though.
- # https://whetstone.privatestorage.io/help/ci/yaml/README.md#allow_failure
- allow_failure: true
script:
- "ci-tools/vulnerability-scan security-report.txt"
artifacts:
diff --git a/ci-tools/vulnerability-scan b/ci-tools/vulnerability-scan
index 94cfd3f8..0a3a7762 100755
--- a/ci-tools/vulnerability-scan
+++ b/ci-tools/vulnerability-scan
@@ -37,4 +37,18 @@ fi
# config. vulnix exit status indicates what vulnix thinks happened. If we
# upgrade to a newer GitLab then we can make GitLab pipeline behavior vary
# based on this.
+#
+# For now, allow 0 (no errors), 1 (only whitelisted errors), and 2
+# (non-whitelisted errors). 3 indicates unexpected error so we let that
+# propagate.
+set +e
nix-shell -p vulnix --run 'vulnix ./scan-target/' | tee "$OUTPUT"
+vulnix_status=$?
+set -e
+
+echo "vulnix status: $vulnix_status"
+if [ $vulnix_status -eq 3 ]; then
+ exit $vulnix_status
+else
+ exit 0
+fi
--
GitLab