Invert the logic for deciding when to soft-fail a cargo audit run
Forgot that this also gets run in `grapl/merge`, since that pipeline
re-runs the contents of `grapl/verify`!
Since `grapl/cargo-audit` is the only run that we want to fail, we'll
just base the test around that pipeline name.
# Dynamically generate a pipeline for running cargo audit. It's only
# dynamic because we need a way to control the `soft_fail` behavior.
#
-# If we're running in the context of the `grapl/verify` pipeline, we
-# want to be able to fail this job without failing the whole pipeline;
-# in that scenario, it's purely an advisory job.
+# If we're running in the context of the `grapl/cargo-audit` pipeline
+# (on a weekly schedule) we want to fail, because then we can get
+# notified in Slack, etc.
#
-# If we're running elsewhere, though, such as in our own dedicated
-# pipeline on a scheduled basis, we *do* want to fail, because then we
-# can get notified in Slack, etc.
+# If we're running elsewhere, such as `grapl/verify` or `grapl/merge`,
+# then we want to be able to fail this job without failing the whole
+# pipeline; in that scenario, it's purely an advisory job.
#
# Absent a dynamically-generated pipeline like this, there isn't
# really a good way to achieve this without a lot of duplication.
set -euo pipefail
-if [ "${BUILDKITE_PIPELINE_NAME}" == "grapl/verify" ]; then
- soft_fail="true"
-else
+if [ "${BUILDKITE_PIPELINE_NAME}" == "grapl/cargo-audit" ]; then
soft_fail="false"
+else
+ soft_fail="true"
fi
cat <<EOF
