Skip to content

chore(ci): run the dependency check daily instead of weekly - #233

Merged
lesnik512 merged 1 commit into
mainfrom
ci/daily-dep-check
Sep 20, 2026
Merged

lesnik512 merged 1 commit into
mainfrom
ci/daily-dep-check

Conversation

@lesnik512

Copy link
Copy Markdown
Member

What this fixes

_checks.yml already documents the hazard for the floors job: a release published upstream today
"can turn it red for reasons no PR here caused", which is why that job is off for pull requests and
runs from scheduled.yml, where a failure opens a tracking issue rather than blocking a merge.

Newest resolution has the same hazard and none of that protection. Nothing here is pinned, so it is
equally exposed, and it runs on every pull request via ci.yml.

That is what happened on Saturday. faststream 0.7.6 published at 09:27 UTC; BrokerUsecase gained a
third type parameter and ty began rejecting RedisBroker. main had last been green at 08:42 UTC.
The first thing to notice was #231, an unrelated Sentry change, where it looked like the author's
fault. The tracking-issue path never fired, because it only covers the floors job.

The detector was also a week wide: scheduled.yml ran Mondays 06:00 UTC, so the gap between that
release and the next scheduled check was about 44 hours.

The change

One line of cadence, plus the wording that referred to it.

  • scheduled.yml cron moves from 0 6 * * 1 to 0 6 * * *.
  • report-scheduled-failure.sh no longer calls the check "weekly", in the issue body and in the
    label description.

lowest-direct: true is unchanged, so the daily run continues to cover both resolutions. No new
inputs, no job splitting.

Why this shape

Pinning would remove the ambush entirely, but a committed lock hides upstream breakage instead of
surfacing it, and fresh resolution is deliberately the early-warning system here. So the fix is to
make the warning reach main first, not to silence it. It bounds the window at roughly a day rather
than eliminating it, which is the most that is available without pinning.

Cost is not a factor: the repository is public, so GitHub-hosted runners are free.

report-scheduled-failure.sh already dedupes (it opens one issue per failure streak and comments on
it thereafter), so a daily cadence adds a comment per day while something is broken rather than an
issue per day.

Verification

No test covers .github, so there is no test seam for a cadence change. I parsed the workflow to
confirm the result rather than eyeballing the diff:

crons: ['0 6 * * *']
checks.with: {'lowest-direct': True}
report-failure if: failure() && github.event_name == 'schedule'

bash -n on the script passes, and just lint-ci and just test are clean (307 passed).

Not included

security-audit.yml still runs weekly on Mondays. It is a different workflow with a different
purpose and is out of scope here.

The lowest-direct job runs only scripts/floor_smoke.py, not ty or pytest, so nothing in CI
checks that the three-parameter BrokerUsecase annotation typechecks at the declared 0.6 floor. I
verified that by hand when fixing it. Worth a separate decision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant