ci: fix dispatch chain — download-index fan-out + redirector ends with directory regen#311
Conversation
The 'Generate directory' step at the end of data-update-download-index was firing repository_dispatch with event-type 'Infrastructure: Update redirector', which is the listener key for infrastructure-update-redirector-config.yml — a different workflow. The step name and intent point at generate-web-directory.yml, which listens for 'Web: Directory listing' (matching the event-type used by every other dispatch in this repo: data-update-image-info.yml, data-update-base-files-info.yml, data-update-jira-excerpt.yml, generate-keyring-data.yaml, generate-build-lists.yaml, repository-status.yaml). Result of the bug: the directory regen never ran after a download index update. The redirector job would still pick up the dispatch but that's a different concern from what the step was meant to do.
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The original step did one dispatch with a misleading 'Generate
directory' label but 'Infrastructure: Update redirector' event-type —
which only fired infrastructure-update-redirector-config.yml. The
intent is to do BOTH after the download index lands:
1. infrastructure-update-redirector-config.yml so the public
redirector picks up the new mapping (event-type
'Infrastructure: Update redirector').
2. generate-web-directory.yml so github.armbian.com regenerates
against the freshly published armbian-images.json (event-type
'Web: Directory listing').
Split into two named steps so each dispatch's purpose is visible in
the run log instead of one step doing one thing under another's name.
Add a second dispatch step at the end of the Close job so the public github.armbian.com directory listing regenerates after every redirector update — currently the redirector ends with a 'Run webindex update action' step that fires 'Data: Update download index' via GITHUB_TOKEN, which GitHub suppresses for same-repo dispatches (no actual run). Use the org PAT (secrets.DISPATCH) for this new step so the dispatch actually fires. Keep the existing GITHUB_TOKEN-using step intact — its suppression is what breaks the redirector → download-index → redirector loop now that download-index dispatches 'Infrastructure: Update redirector' (companion change in this PR). Comment added on that step so a future maintainer doesn't 'fix' it.
Per review: the directory regen after redirector isn't actually wanted here — download-index already dispatches Web: Directory listing, and download-index runs after redirector via the existing chain. Adding it on the redirector side too would just trigger a duplicate directory regen. Keep the GITHUB_TOKEN-explanation comment on the existing 'Run webindex update action' step — the same loop concern still applies (download-index dispatches 'Infrastructure: Update redirector' via the org PAT, so flipping the redirector-side token to DISPATCH would create redirector → download-index → redirector forever).
Replace the Close job's tail step from 'Run webindex update action'
(GITHUB_TOKEN-suppressed dispatch of 'Data: Update download index')
with 'Generate directory' (DISPATCH-fired 'Web: Directory listing').
Rationale:
- The directory listing is what we actually want regenerated when
the redirector publishes new YAML to the data branch.
- The old step was a no-op since GitHub suppresses GITHUB_TOKEN
same-repo dispatches.
- Dropping it also removes the would-be loop concern from the
companion change in this PR (download-index now dispatches
'Infrastructure: Update redirector') — there's no longer any
redirector → download-index arrow at all.
What this PR fixes
Two related dispatches around the public download index / directory listing were either pointing at the wrong listener or were no-ops.
1. `data-update-download-index.yml` — "Generate directory" step targeted the wrong workflow
The final step was named "Generate directory" but dispatched `event-type: "Infrastructure: Update redirector"` — which fires `infrastructure-update-redirector-config.yml`, not `generate-web-directory.yml`. The directory regen never ran after a download-index update.
Split into two correctly named/typed steps so both downstream workflows fire:
```yaml
name: "Update redirector config"
event-type: "Infrastructure: Update redirector" # → infrastructure-update-redirector-config.yml
name: "Generate directory"
event-type: "Web: Directory listing" # → generate-web-directory.yml
```
2. `infrastructure-update-redirector-config.yml` — Close job tail dispatch was a no-op
The Close job ended with a `Run webindex update action` step that used `GITHUB_TOKEN` to dispatch `Data: Update download index`. GitHub suppresses GITHUB_TOKEN-fired dispatches for same-repo listeners, so it was effectively a no-op.
Replace with a `Generate directory` step that dispatches `Web: Directory listing` via the org PAT — which is what should happen after the redirector publishes new YAML to the `data` branch.
Resulting graph (loop-free)
```
download-index → redirector + directory
redirector → directory
```
No `redirector → download-index` arrow at all (was suppressed before, removed now), so no loop is possible.
Test plan