-
Notifications
You must be signed in to change notification settings - Fork 149
Automation: Pull Requests
aslakknutsen edited this page May 17, 2012
·
8 revisions
- GitHub -> On PullRequest (Opened/Changed/Comment)
- WebHook -> Hubot /github/pullrequest
- scan comments for @ike commands, verify command issuer has push request to given repo(admins, module lead)
- WebHook -> Hubot /github/pullrequest
// create a JIRA issue for pull request if missing from pull request
@ike jira create {
subject: "Should be able to do bla bla",
body: "When something something",
version: "1.0.0.next",
component: "Extension - Seam2" (default given based on repository)
}
@ike response: Created jira issue ARQ-513 (URL)
// Resolve given issue number,
// number is optional (taken from subject / commit message / comments if only one given)
@ike jira resolve (ARQ-513)
@ike response: Resolved | Multiple found (ARQ-XX, ARQ-YY), please specify
// create a build job for the branch, rebase
// (, squash into one commit with message if message defined)
@ike push {
message: "ARQ-513 Add support for bla bla"
}
@ike response:
"Build started, jenkins_job_url"
// when build complete
"Failed to rebase, please fix issues and try again"
"Build failed, jenkins_job_url, please fix issues and try again"
"Build ok, jenkins_job_url. Request pushed upstream, upstream_commit_url" (close pull request)
On PullRequest
-
if pullrequest is from a forked master branch (upstream branch == fork branch?)
- Ike could respond with information about topic branches and how to recover from squashed upstream master
-
Transision associated JIRA issue to "Link Pull Request"
-
Resolve associated JIRA issue on merge
-
if pullrequest commit messages does not contain a jira issue
- Ike could respond with a note that a jira is 'required' pr commit
When we automate releases, e.g. monthly, API/SPI stability becomes very important. We need rules for binary compatibility with previous release etc (japi-checker?). Deprecation rules should change from release based to time based. When this should be removed could be automated. When a pullrequest is approved (merged), we can scan the diff/patch for "+ .*@deprecated" and add a JIRA { title: "Remove API deprecated in XX", duedate: now()+6months }