Starting around Nov 1, 2020, multiple repositories that were configured to run jobs daily started running only every other day. All of the examples I’ve seen are configured to not run if there’s been a build in the last 24 hours, I wonder if that’s perhaps counting the most recent cron run? Anyway, seems like a definite bug.
Examples:
I think that the recency check is preventing a run. Try deleting this cron job and replacing with an identical one but configured to “always run”.
Not sure what may have changed in the indicated time frame.
Indeed, disabling the recency check works around the issue. Perhaps something about the recency check changed around Nov 1, 2020 to erroneously count the previous day’s cron run as a “recent” run.
I believe Travis first does the recency check and then schedules the build. So the 2nd time around, the check sees that there was a build within the last 24h – the one from the cron job – and doesn’t schedule another.
So I’d say what you see now is the correct behavior – or at least, the behavior corresponding to the description: since a job takes some time to run, there will be less than 24h between builds if a build is run every day. Even if we only consider build start times, there will be cases of less than 24h between builds due to start time flucuations.
I understand what you are saying, but disagree that this is expected behavior.
Taken literally, this option creates a race condition based on whether the previous cron run was 23:59 or 24:01 ago. Surely race conditions are not desirable behavior? The behavior should at least be explicit and deterministic, even if it is in fact every 48 hours.
But I expect if you survey customers, most would expect that a daily job runs… well, daily… regardless of whether that box is checked.