Coder Social home page Coder Social logo

ghpullrequest-validator's Introduction

Github Pull Request Validator

A tool for automatically validating github pull requests with Jenkins

Configuring

Here's an example ghpr.conf file.

scala: {
  jenkins: {
    url = "https://my.company.com/jenkins"
    user: {
      user = "buildbot"
      password = "MY PASSWORD IS SECRET"
    }
    jobs: [ "flush-silly-mistakes" ]
  }
  github: {
    user: {
      user = "gh-commenter"
      password = "MY PASSWORD IS SECRET"
    }
    project: {
      user = "myname"
      project = "myproject"
    }
  }
}

The outer object is given any random name. This name represents the "project" name used in logging. The inside is made up for two config blocks: jenkins and github.

The jenkins configuration consists of:

  • url - The location where we can access Jenkins REST API. Right now, that's the same as the website URL.
  • user - A user/password pair we should use to log in to Jenkins and execute builds.

The github configurations consists of:

  • user - The credentials of a github user that can comments on pull requests.
  • project - The user/project github combo of which project to monitor. e.g. "scala/scala" or "jsuereth/scala-arm"

Setting up Jenkins

Any jenkins job will work for validating pull requests, as long as it supports two build parameters:

  • mergebranch - The branch to merge the pullrequest onto. This lets us test for merge-related build failures.
  • pullrequest - The pull request number from github. This is the code that should be merged in.

Here's an example bash script that, when run inside jenkins on an appropriate repository, can resolve the appropriate git commit:

newbranchname="pull-$pullrequest-merge"
# Checkout
git checkout $mergebranch
# Update branch
git pull origin $mergebranch
# Create new merging branch
git checkout -B $newbranchname
# Fetch pull request and merge into new branch.
git fetch origin "+pull/${pullrequest}/head:pullreq/${pullrequest}"
git merge "pullreq/${pullrequest}"

Contributing

If you'd like to contribute to the GHPRValidator project, please sign the contributor's licensing agreement.

License

Copyright 2012 Typesafe, Inc.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

ghpullrequest-validator's People

Contributors

adriaanm avatar bantonsson avatar dotta avatar dragos avatar jamesward avatar jsuereth avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ghpullrequest-validator's Issues

needy-seeming PR spurns attentions lavished by desperate programmer

The list of issues at scala/scala presently has 2341 marked with the big red "needs attention". It is wonderful having the issues partitioned with these tags; however it is important that the tags mean what they say. In this case, the tag should be "needed attention once upon a time, but such attention as can be given has been given."

I understand that if/when the tests all pass the tag will be updated, but that leaves a very large window during which it is marked "need attention" but no more attention is possible. So I propose as soon as a PR has been modified in such a way that known-failing commits are no longer present, the "needs attention" tag should be removed.

NoSuchElementException: next on empty iterator

    ERROR] [01/23/2014 11:09:59.918] [default-akka.actor.default-dispatcher-94112] [akka://default/user/ghpr-2/akka+akka/pull-request-checker] next on empty iterator
    java.util.NoSuchElementException: next on empty iterator
            at scala.collection.Iterator$$anon$2.next(Iterator.scala:39)
            at scala.collection.Iterator$$anon$2.next(Iterator.scala:37)
            at scala.collection.IndexedSeqLike$Elements.next(IndexedSeqLike.scala:64)
            at scala.collection.IterableLike$class.head(IterableLike.scala:91)
            at scala.collection.mutable.ArrayOps$ofRef.scala$collection$IndexedSeqOptimized$$super$head(ArrayOps.scala:105)
            at scala.collection.IndexedSeqOptimized$class.head(IndexedSeqOptimized.scala:120)
            at scala.collection.mutable.ArrayOps$ofRef.head(ArrayOps.scala:105)
            at scala.collection.TraversableLike$class.last(TraversableLike.scala:455)
            at scala.collection.mutable.ArrayOps$ofRef.scala$collection$IndexedSeqOptimized$$super$last(ArrayOps.scala:105)
            at scala.collection.IndexedSeqOptimized$class.last(IndexedSeqOptimized.scala:126)
            at scala.collection.mutable.ArrayOps$ofRef.last(ArrayOps.scala:105)
            at backend.PullRequestChecker$$anonfun$backend$PullRequestChecker$$checkPullRequest$1.apply(PullRequestChecker.scala:226)
            at backend.PullRequestChecker$$anonfun$backend$PullRequestChecker$$checkPullRequest$1.apply(PullRequestChecker.scala:225)
            at scala.collection.immutable.List.foreach(List.scala:318)
            at backend.PullRequestChecker.backend$PullRequestChecker$$checkPullRequest(PullRequestChecker.scala:225)
            at backend.PullRequestChecker$$anonfun$receive$1.applyOrElse(PullRequestChecker.scala:47)
            at akka.actor.ActorCell.receiveMessage(ActorCell.scala:498)
            at akka.actor.ActorCell.invoke(ActorCell.scala:456)
            at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:237)
            at akka.dispatch.Mailbox.run(Mailbox.scala:219)
            at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:386)
            at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:262)
            at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:975)
            at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1478)
            at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:104)

Per-branch job validation

It'd be great to be able to configure the jobs that need to be run per branch. This is very useful for projects that support multiple Scala versions. For example, in the IDE we have:

  • master -> supports scala 2.10.2-SNAPSHOT and 2.11.0-SNAPSHOT
  • release/3.0.x -> supports 2.9.3 and 2.10.2-SNAPSHOT

Each Scala version has its own Jenkins job.

While a Jenkins job can check the mergebranch and "do nothing", it's not working well with some Jenkins plugins. For example, the JUnit results collector fails the build if there are no (new) test results.

Github API Pagination breaks comment detection

Github paginates reponse lists. Although we upped the per_page size to 11... err 100, we can't be sure that this solves the whole problem. We should update the Github API so that we can read all results rather than just the first page.

Note: Probably easiest to make some kind of buffering/blocking collection for now...

split config of jobs to start and those to monitor for success

Read this first [edited]:
Note that I do NOT propose to have the build bot schedule anything. The only tweak is to have the build bot know which jobs are triggered by jenkins as a result of the job that it starts, so that it can monitor the result of those jobs for error reporting.

Original, poor phrasing:
I think we should make the build bot more flexible: we should be able to specify which jobs to start and which jobs to monitor for completion.

This way we can create more complex flows (such as for IDE PR validation), where we run three jobs A, B and C for validation, but where job C must run after job B (using Jenkins as a scheduler). All jobs must still complete for the PR to validate in this scenario, but you could also imagine running jobs without monitoring them.

always comment upon failure

currently a rebuild does not lead to a new failure comment if it also fails; this makes it difficult to find out what the actual failure was in failures after the first try

rebuilding suggestions

Busy programmers are unlikely to restart test runs with surgical precision; I am sure the stats bear out that "PLS REBUILD ALL" almost has the exclusive. So let's drop "PLS" and "ALL" and let us say "REBUILD".

In addition, it should go without saying that "ALL" (or just "REBUILD") actually means to only rebuild failed commits. If jenkins has already recorded that some particular commit is a success, then who are we to say otherwise - if we do have issues with false positives on that point, that's a much bigger problem, and one not properly addressed by shouting bits of pidgin english over the intertubes.

In the best case (this is somewhat more ambitious) jenkins would recognize when I've just rebased 25 already-succeeded commits in order to fix a comment in #4, and would find a way to run something fewer than 25 new test runs at 30-60 minutes a pop, saving as much as one fraction of a tree in energy costs.

Detect existing jenkins builds on restart

Right now, if the PR validator is restarted, it doesn't detect whether an existing jenkins job has been started. It should do so and then watch that build to comment on the result.

Validate user has signed Typesafe CLA

Would be handy if the validator could make sure that the user who created the PR has signed the Typesafe CLA. If it hasn't yet, the validator should point the user to the online Typesafe CLA and explain that the PR cannot be accepted until the CLA is signed.

Changing the messages the kitty generates

How about producing

FAILED pr-rangepos: https://scala-webapps.epfl.ch/jenkins/job/pr-rangepos/1837/

instead of

jenkins job pr-rangepos: FAILURE - https://scala-webapps.epfl.ch/jenkins/job/pr-rangepos/1837/

Pros: 1) less text, 2) status is the first line in the email body => it will be shown in email previews even on devices with small screens.

/cc @adriaanm

don't use String to represent SHAs internally

one reason to make sure to resolve commit SHAs to a standard, sufficiently long representation, is that github's commit status api does not recognize deadbeef and deadbee as shas for the same commit

quiet down logging

I tried changing the log level to INFO in src/main/resources/application.conf, but I keep seeing lines like:

[DEBUG] [07/09/2013 23:32:03.949] [default-akka.actor.default-dispatcher-5] [akka://default/user/$a/$d/$a] ....

Also, I'd like to either drop the [default-akka.actor.default-dispatcher-5] [akka://default/user/$a/$d/$a] bit or learn how to interpret it :-)

Archive?

Is this still in use? Should we archive the repo?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.