Track Actions Status in Issue Comment Responder #228
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR implements a tracking system for GitHub Actions workflow runs triggered via issue comments. When a user posts a /ci command, the system now generates a correlation ID, dispatches workflows with that ID in their run names, and continuously monitors those runs to provide real-time status updates in the PR thread.
Key Changes:
- Added correlation ID generation and tracking for dispatched workflow runs
- Implemented a watcher job that polls for matching runs and updates PR comments with status
- Updated all workflow files to include correlation IDs in their run names for discoverability
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| .github/workflows/issue-comment.yml | Added correlation ID generation, job outputs, watcher job with polling logic, and status tracking |
| .github/workflows/tests-full.yml | Added dynamic run-name that includes correlation ID from repository_dispatch events |
| .github/workflows/examples-unsloth.yml | Added dynamic run-name that includes correlation ID from repository_dispatch events |
| .github/workflows/examples-spider.yml | Added dynamic run-name that includes correlation ID from repository_dispatch events |
| .github/workflows/examples-compat.yml | Added dynamic run-name that includes correlation ID from repository_dispatch events |
| .github/workflows/examples-apo.yml | Added dynamic run-name that includes correlation ID from repository_dispatch events |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| .sort() | ||
| .join('|'); | ||
| const deadlineMs = Date.now() + 175 * 60 * 1000; // 175 minutes |
There was a problem hiding this comment.
The 175-minute deadline is hardcoded but appears arbitrary given the 180-minute job timeout. Consider extracting this as a constant with a clear relationship to the job timeout (e.g., TIMEOUT_MINUTES - 5) to make the intent explicit and easier to maintain if the job timeout changes.
| const deadlineMs = Date.now() + 175 * 60 * 1000; // 175 minutes | |
| const TIMEOUT_MINUTES = 180; // Must match 'timeout-minutes' above | |
| const WATCHER_DEADLINE_MINUTES = TIMEOUT_MINUTES - 5; // 5 minute buffer before job timeout | |
| const deadlineMs = Date.now() + WATCHER_DEADLINE_MINUTES * 60 * 1000; |
| github.rest.actions.listWorkflowRunsForRepo, | ||
| { owner, repo, event: 'repository_dispatch', per_page: 100 } | ||
| ); | ||
| const cutoff = new Date(Date.now() - 60 * 60 * 1000); // last hour |
There was a problem hiding this comment.
The 1-hour lookback window is hardcoded. If workflow dispatch takes longer to create runs or if there are clock skew issues, runs could be missed. Consider extracting this as a configurable constant or making it relative to the comment/trigger timestamp for more reliable run discovery.
| break; | ||
| } | ||
| core.notice(`No runs found yet for correlation '${correlationId}'; retrying shortly.`); | ||
| await new Promise(res => setTimeout(res, 10000)); |
There was a problem hiding this comment.
The 10-second polling interval for initial run discovery is hardcoded. Extract this as a named constant (e.g., INITIAL_POLL_INTERVAL_MS) to improve readability and make it easier to tune if needed.
| core.notice(`All runs for correlation '${correlationId}' completed; stopping watcher.`); | ||
| break; | ||
| } | ||
| await new Promise(res => setTimeout(res, 60000)); |
There was a problem hiding this comment.
The 60-second polling interval for status updates is hardcoded. Extract this as a named constant (e.g., STATUS_POLL_INTERVAL_MS) to improve readability and make it easier to adjust polling frequency.
| const refreshed = []; | ||
| for (const id of ids) { | ||
| const { data } = await github.rest.actions.getWorkflowRun({ | ||
| owner, | ||
| repo, | ||
| run_id: id | ||
| }); | ||
| refreshed.push(data); | ||
| } | ||
| return refreshed; |
There was a problem hiding this comment.
The refreshRuns function performs sequential API calls for each workflow run. With multiple runs, this creates unnecessary latency. Consider using Promise.all() to fetch all run statuses concurrently, which would significantly reduce the refresh time.
| const refreshed = []; | |
| for (const id of ids) { | |
| const { data } = await github.rest.actions.getWorkflowRun({ | |
| owner, | |
| repo, | |
| run_id: id | |
| }); | |
| refreshed.push(data); | |
| } | |
| return refreshed; | |
| const promises = ids.map(id => | |
| github.rest.actions.getWorkflowRun({ | |
| owner, | |
| repo, | |
| run_id: id | |
| }).then(({ data }) => data) | |
| ); | |
| return Promise.all(promises); |
No description provided.