Skip to content

Automation: Pull Requests

aslakknutsen edited this page May 17, 2012 · 8 revisions

GitHub -> Hubot -> Jenkins

  • 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)
// 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)

Automated Validation

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

Automated Deprecation

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 }