Repository navigation
Daniel Ridge bot stopped running - re-enable its disabled workflow and prevent it recurring #180
Description
Overview
We need to restore @danielridgebot's GitHub Pages dependency checks and correct its wiki page, because GitHub disabled the bot's scheduled workflow for repository inactivity on 2026-01-07 and nothing has been checking the Ruby or github-pages gem versions since.
Action Items
The bot's code lives in danielridgebot/check-ghpages-versions, a repo under a personal account rather than the hackforla org. You need write access there.
- Re-enable
Check Github Pages Gem Version and Open New Issue on Changein that repo's Actions tab (it shows as disabled with a re-enable banner). GitHub disables scheduled workflows after 60 days of no repo commits; the last commit was 2025-10-31 and the last run 2026-01-07. - Confirm
check-ruby-version.ymlstarts running again. It reports as active but its only automatic trigger isworkflow_runon the workflow above, so it has been dead too — the Actions UI does not show this. - Add a keepalive so this cannot silently recur. The wiki claims one was already added, but it has never existed in either workflow file. Either add gautamkrishnar/keepalive-workflow, or give
check-ruby-version.ymlits ownschedule:so it no longer depends on the other workflow firing. - In both workflows, change
gh issue create --repo "github.com/hackforla/ops"tohackforla/devops. The redirect works, so this is cleanup, not a fix. - Verify
secrets.DR_PAThas not expired. It was last confirmed working 2025-05-07 (GHPAGES-DOCKER Build Was Successful #154). If it is a fine-grained PAT it has a max 1-year lifetime and is likely dead; issue creation would fail silently on the next real version bump. - Test end to end rather than waiting for GitHub Pages to bump. Temporarily set
release-versions/github-pages-gem.txtto an older value and run the workflow viaworkflow_dispatch, confirm an issue lands on hackforla/devops with its labels, milestone and board card, then restore the file. Commits0ce0791f/18f58201in that repo are a previous run of exactly this test. - Update the wiki page @danielridgebot-DevOps-Wiki — remove the false keepalive claim under "Solution", and replace the "What's next" bullet "figure out why it stopped creating new issues (last opened issue was Oct 6, 2022)", which is wrong: it opened issues in Aug 2024 (GHPAGES-DOCKER needs to be updated - GitHub pages gem #141, GHPAGES-DOCKER needs to be updated - ruby gem #142, GHPAGES-DOCKER needs to be updated - GitHub Pages Ruby Gem #143, GHPAGES-DOCKER needs to be updated - Ruby #144) and May 2025 (GHPAGES-DOCKER Build Was Successful #154).
- After the wiki edit, load the live page and confirm both of those claims are gone.
Resources/Instructions
- Bot repo: https://github.com/danielridgebot/check-ghpages-versions
- Wiki page: https://github.com/hackforla/devops/wiki/@danielridgebot-DevOps-Wiki
- Upstream source of truth: https://pages.github.com/versions.json — currently
github-pages 232/ruby 3.3.4, matching the bot's stored values, so no real bump is pending. That is why nothing is visibly broken today, and why this needs testing rather than waiting. - Related: Daniel Ridge Bot issue template for updates requested needs to be improved #52 (bot issue-template improvements, already delivered as bot-repo PR Add #ops members to HackForLA's AWS #25)
- File and commit references above were accurate on 2026-08-24 and may drift; locate files by name rather than by position.
Activity
ale210 commentedon Aug 24, 2026
Done. All action items are complete; notes on two things that differed from the ticket as written.
The bot repo is already in the org. The Overview says it "lives in danielridgebot/check-ghpages-versions, a repo under a personal account rather than the hackforla org." That URL redirects — it is
hackforla/check-ghpages-versions(same repo, created 2022-06-23). No transfer or extra access was needed. Leaving the body text as-is for the record.The suggested keepalive action no longer exists. GitHub has blocked
gautamkrishnar/keepalive-workflowfor a ToS violation since 2025-04-21, souses:can no longer resolve it. Replaced with a hand-rolledkeepalive.yml: weekly schedule, empty commit only once the repo has been idle more than 50 days. It is a separate workflow rather than a step insidecheck-gh-pages-version.ymlon purpose — a keepalive living inside that workflow dies with it, which is the exact failure being fixed here.What was delivered, in hackforla/check-ghpages-versions#26 plus settings changes:
check-ruby-version.ymlnow has its own daily schedule (12:15 UTC) instead of theworkflow_runtrigger.Check Github Pages Gem Version and Open New Issue on Changere-enabled; all four workflows now active.hackforla/devops.test-issue-labels.ymlwas also broken and is fixed — it authenticated withsecrets.Daniel_Ridge_PAT, which does not exist in the repo. Found in passing, outside this issue's scope.secrets.DR_PATis alive. The end-to-end test created #181 on this repo with all five labels, the correct milestone and a board card, then self-restoredgithub-pages-gem.txtto 232 via its own commit. #181 is closed and its card removed. The ruby workflow was separately dispatched and correctly ran, found no change, and created nothing — confirming it no longer depends on the other workflow.The wiki page is corrected and verified live: the false keepalive claim is replaced with an accurate description of the new workflow and the 60-day rule that caused the outage, the ruby trigger description is updated, and the stale
danielridgebot/links are re-pointed.Worth a follow-up ticket:
DR_PATis a personal token with a rotation cliff. Now that the repo is in the org it can readHFLA_WORKFLOW_APP_ID/HFLA_WORKFLOW_APP_PRIVATE_KEY, so moving the workflows onto the GitHub App would retire that class of failure rather than resetting the clock.