Keep Dart tasks in sync with your GitHub pull requests

When a pull request is opened, closed, or merged in GitHub, I want a deterministic workflow that keeps the linked Dart task in sync so nobody on the team updates status by hand. Trigger it from a GitHub webhook subscribed to pull request events, covering opened, closed, and closed-with-merged.

Step one is to read the Dart task ID out of the pull request branch name, falling back to the pull request title if the branch does not contain one. Branches are named like feature/DART-123-new-login, so match the task ID token wherever it appears in the string. If no task ID is present in either place, stop immediately without doing anything else. This early exit matters: most pull requests in a repository are not linked to Dart work, and the workflow must not error or comment on them.

With a task ID in hand, call GitHub Get a Pull Request to read the current state of the pull request: title, author login, html_url, state, and the merged flag. Do not trust the webhook payload alone for the merge decision, read it back from the pull request. Then call Dart Get Task with the parsed ID to confirm the task actually exists. If the task is not found, stop quietly rather than failing loudly.

Resolve status names through Dart Get User Space Configuration rather than hardcoding them, so the workflow uses whatever statuses the workspace actually has. Pull the list of valid statuses and match case-insensitively against the ones meaning in review, done, and in progress. If the workspace has no matching status for a given transition, skip the status update but still write the comments.

Then apply the mapping with Dart Update Task. A pull request that was opened sets the task to the In Review status. A pull request that was closed with merged true sets it to Done. A pull request that was closed with merged false sets it back to In Progress. There is no judgement call anywhere: three known pull request states map to three resolved statuses.

On every transition, add a Dart Create Comment on the task recording the pull request title, the author, the link to the pull request, and the status the task was just moved to. Finally, post exactly one GitHub Create an Issue Comment back on the pull request confirming which Dart task was updated and to what status. Pull requests are issues in GitHub's API, so the issue comment operation works with the pull request number. One comment on the task and one comment on the pull request per event, never duplicates.