Add GitHub Copilot agents for automated PR verification, daily code review, and issue triage#269
Add GitHub Copilot agents for automated PR verification, daily code review, and issue triage#269YunchuWang wants to merge 1 commit intomainfrom
Conversation
…eview, and issue triage Adds the same Copilot agent setup used in durabletask-js, adapted for the Java/Gradle context: - .github/copilot-instructions.md: Repository context for AI assistants - .github/agents/pr-verification.agent.md: Autonomous PR verification agent - .github/agents/daily-code-review.agent.md: Daily code review agent - .github/agents/issue-triage.agent.md: Issue triage and labeling agent - .github/workflows/pr-verification.yaml: GitHub Actions workflow for PR verification - .github/workflows/daily-code-review.yaml: GitHub Actions workflow for daily code review
There was a problem hiding this comment.
Pull request overview
Adds GitHub Copilot agent infrastructure to automate PR verification and daily code review in this Gradle/Java DurableTask SDK repo, plus a repository-specific instruction document to ground agent behavior in core determinism and build/testing constraints.
Changes:
- Adds scheduled/manual GitHub Actions workflows for PR verification and daily code review using the Copilot CLI.
- Adds three agent definition files (PR verification, daily code review, issue triage) under
.github/agents/. - Adds
.github/copilot-instructions.mddocumenting key architecture, build commands, testing approach, and conventions for AI assistants.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/pr-verification.yaml |
New scheduled workflow to run a PR verification agent against the DTS emulator and update PR/issue metadata. |
.github/workflows/daily-code-review.yaml |
New scheduled workflow to run a daily code review agent that can open a single “copilot-finds” PR per run. |
.github/copilot-instructions.md |
New repository context document for agents (execution model, determinism rules, modules, build/test commands). |
.github/agents/pr-verification.agent.md |
Agent spec for verifying labeled PRs by generating/running a verification sample and posting evidence. |
.github/agents/daily-code-review.agent.md |
Agent spec for scanning the repo and opening one high-confidence fix PR with tests. |
.github/agents/issue-triage.agent.md |
Agent spec for issue labeling/maintenance and duplicate detection. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ## Testing Approach | ||
|
|
||
| - **Unit tests:** JUnit-based, in `client/src/test/` | ||
| - **Integration tests:** Run against DTS emulator, in `client/src/test/` (integrationTest source set) |
There was a problem hiding this comment.
This describes integration tests as being in an "integrationTest source set", but the Gradle setup in client/build.gradle runs integration tests via a dedicated integrationTest task that filters JUnit tags (no separate source set). Updating this wording will prevent contributors/agents from looking for a non-existent source set.
| - **Integration tests:** Run against DTS emulator, in `client/src/test/` (integrationTest source set) | |
| - **Integration tests:** JUnit tests in `client/src/test/` that run against the DTS emulator via the dedicated Gradle `integrationTest` task (uses JUnit tags to select tests) |
| ### Sample Guidelines | ||
|
|
||
| - The sample must read like **real application code**, not a test. | ||
| - Structure the code as a customer would: create worker → register orchestrations → | ||
| register activities → start worker → schedule orchestration → await result → validate. | ||
| - Use descriptive variable/function names that relate to the customer workflow. | ||
| - Add comments explaining the customer scenario and why this workflow previously failed. | ||
| - Keep it minimal — only the code needed to reproduce the scenario. |
There was a problem hiding this comment.
Verification samples that this agent generates should include the repository’s standard Microsoft MIT license header at the top of the Java file. Existing samples under samples/src/main/java/io/durabletask/samples/ include this header (e.g., ChainingPattern.java), and missing it could break consistency or downstream checks.
| # Security: This workflow has write permissions to contents, issues, and PRs, so | ||
| # it must NOT use the `pull_request` trigger (which checks out untrusted PR code | ||
| # and could exfiltrate the job token). Instead, it runs on schedule/manual | ||
| # dispatch only. The agent fetches each PR's branch itself before building and | ||
| # verifying. The contents:write permission is needed to push verification sample | ||
| # code to verification/pr-<N> branches. | ||
| on: | ||
| # Run periodically to pick up PRs labeled pending-verification | ||
| schedule: | ||
| - cron: "0 */6 * * *" # Every 6 hours | ||
|
|
||
| # Allow manual trigger for testing | ||
| workflow_dispatch: | ||
|
|
||
| permissions: | ||
| contents: write | ||
| issues: write | ||
| pull-requests: write |
There was a problem hiding this comment.
The workflow comment claims this avoids checking out untrusted PR code with a write-scoped token, but the agent is instructed to fetch and build PR branches anyway. That still executes untrusted code (Gradle build / sample run) in a job that has contents/issues/pull-requests: write and exposes GH_TOKEN/COPILOT_GITHUB_TOKEN, which can be exfiltrated by a malicious PR. Consider splitting into two phases/jobs: (1) build/run verification with read-only permissions, no secrets, and actions/checkout with persist-credentials: false; (2) a separate job that only posts results / updates labels / pushes verification branch using write permissions, consuming artifacts from phase 1.
|
|
||
| - name: 🐳 Start DTS Emulator | ||
| run: | | ||
| docker run --name dts-emulator -d --rm -p 4001:8080 \ |
There was a problem hiding this comment.
The emulator container is started with --name dts-emulator, but the pr-verification agent instructions later check for a running container named durabletask-emulator and will attempt to start a second emulator if it doesn't find it, likely failing due to port 4001 already being bound. Use a consistent container name across the workflow and agent docs (e.g., durabletask-emulator) so the agent can detect the already-running emulator.
| docker run --name dts-emulator -d --rm -p 4001:8080 \ | |
| docker run --name durabletask-emulator -d --rm -p 4001:8080 \ |
Summary
Adds GitHub Copilot agent infrastructure for automated CI workflows, ported from durabletask-js. All agents and workflows have been adapted for the Java/Gradle context of this repository.
What's Included
Copilot Instructions (
.github/copilot-instructions.md)Repository architectural context for AI assistants — covers the replay execution model, determinism invariants, module structure, build system, error handling patterns, and code conventions.
Agent Definitions (
.github/agents/)pr-verification.agent.mdpending-verification, creates standalone sample apps to exercise the fix against the DTS emulator, posts verification evidence to linked issues, and updates PR labelsdaily-code-review.agent.mdissue-triage.agent.mdGitHub Actions Workflows (
.github/workflows/)pr-verification.yamldaily-code-review.yamlKey Adaptations from durabletask-js
./gradlew build,./gradlew test,./gradlew spotbugsMain)-p 4001:8080to match existing integration test setup)setup-java@v4with Microsoft distribution, JDK 11samples/src/main/java/io/durabletask/samples/verification/Prerequisites
The workflows require the
COPILOT_GITHUB_TOKENsecret to be configured in the repository settings.Testing
These workflows can be tested via manual
workflow_dispatchtriggers once the secret is configured.