This is a problem from yesterday
The SCRIPT part of TRAVIS’s JOB succeeds and runs fine, but I’m having an issue where AFTER_FAILURE is always called.
echo “${TRAVIS_TEST_RESULT}” after each step, but they all return 0 as normal.
$ echo "${TRAVIS_TEST_RESULT}"
0
The command "echo "${TRAVIS_TEST_RESULT}"" exited with 0.
cache.2
store build cache
after_failure.1
0.00s$ echo "${TRAVIS_TEST_RESULT}"
0
after_failure.2
35.14s$ gem install curb
after_failure.3
0.68s$ test/bin/cancel-other-jobs
We’re also seeing this same exact issue - it started around 6AM Eastern on March 28, 2023. With no changes to our scripts or travis.yml, all f our jobs returned 0 and ran the after_failure:
The command "INSTALL_MODE="install" ./canary-scripts/deploy.sh" exited with 0.
$ ./canary-scripts/failure.sh
We experienced the same issue. We had to delete our after_failure step to avoid this unexpected behavior. Are we right thinking that TRAVIS_TEST_RESULT decides if this step fires?
Adding here as it seems likely linked. we’re seeing a weird thing where each of the jobs from our stage are being pumped through after_success even though they had failed.
(Only found this thread when I went to write my own post).
There’s a worse, possibly connected issue. Deployment steps are being run even when the test (“script”) stage fails.
How long does it take to fix what is a potentially catastrophic problem, if a deployment succeeds after tests failed?
We first noticed it happening around 2024-04-11, though further investigation showed it had happened a couple of days before then. It’s 2024-04-19 and it’s still happening.
It also means that deployment scripts are needlessly being run, just wasting lots of CPU cycles and lots of time.