fix: skip deploy when HEAD already successfully deployed (#264) #265

Merged
guettlibot merged 1 commits from refs/pull/265/head into main 2026-05-26 05:35:19 +00:00
guettlibot commented 2026-05-26 04:34:40 +00:00 (Migrated from codeberg.org)

Summary

  • The hourly deploy.yml schedule re-deployed the same commit repeatedly because it always diffed HEAD~1..HEAD — once a commit touching lib//pubspec.* became HEAD, every hourly tick would detect "android changes" and deploy again.
  • Fix: at the start of the check-changes job, query the Forgejo workflow runs API for the last successful deploy.yml run. If its head_sha matches current HEAD, output android=false / linux=false immediately, skipping all downstream jobs.
  • workflow_dispatch bypasses this check (always deploys), matching the existing behaviour.

Test plan

  • Verify the check-changes job exits early on the next scheduled run after a successful deploy of the same commit
  • Verify a new commit still triggers deployment normally
  • Verify workflow_dispatch still deploys unconditionally

🤖 Generated with Claude Code

## Summary - The hourly `deploy.yml` schedule re-deployed the same commit repeatedly because it always diffed `HEAD~1..HEAD` — once a commit touching `lib/`/`pubspec.*` became HEAD, every hourly tick would detect "android changes" and deploy again. - Fix: at the start of the `check-changes` job, query the Forgejo workflow runs API for the last successful `deploy.yml` run. If its `head_sha` matches current HEAD, output `android=false` / `linux=false` immediately, skipping all downstream jobs. - `workflow_dispatch` bypasses this check (always deploys), matching the existing behaviour. ## Test plan - [ ] Verify the `check-changes` job exits early on the next scheduled run after a successful deploy of the same commit - [ ] Verify a new commit still triggers deployment normally - [ ] Verify `workflow_dispatch` still deploys unconditionally 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.