The goal of this project was to create a small Continuous Integration server. This server will receive a Webhook from Github, clone the project, build and run automated Unit tests. It will then update the status of the commit, to note whether it was a success or failure.
The parts of this program were split evenly and implemented mostly individually by all 4 members of the group. The basic code skeleton was decided upon together, including the main ContinuosIntegrationServer file. We then setup a number of issues in Github, and divided them evenly so that one person worked on at least one of the bigger issues: compiling, testing, cloning, commit status and logging.
We believe that our co-operation was remarkable. All of the pull requests were properly tested and code-reviewed by a peer to make sure that everything works and looks fine. This also gives room for improvement, since we receive feedback of things that we might not have thought of ourselves when writing the code. It also ensures that everyone is inline with what the code is doing, and knows how everything works. The pull requests were then merged by a peer as well.
Another thing we would like to bring up is the structure of the project. We have made sure to implement well defined classes for each component which does one thing, and makes Unit testing a lot easier. For instance, we have one class for compiling and class for running unit tests. This also makes it easier to work as a group on separate parts of the project.
For building and package management we are using Maven.
https://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
To build a JAR file with dependencies use the following command:
mvn clean compile assembly:single
And to run it:
java -cp target/assignment2-1.0-SNAPSHOT-jar-with-dependencies.jar kth.soffgrupp.se.ContinuousIntegrationServer
The documentation can be generated by building the program and then running the command:
mvn javadoc:javadoc
The documentation is then available as a web page at ./target/site/api-docs/index.html.
The documentation includes private members for visibility.
To run automated tests, use the following command:
mvn test
To add a dependency, edit the pom.xml file and add the dependencies under plugins.
Dependencies used in the project are:
- jUnit
- javax servlet
- eclipse jetty
- org.json
- commons-io
- github-api
- google gson
Once a webhook is received from Github, the corresponding repository is cloned in to the test/ folder. This folder also checks-out the branch of which was regarded in the webhook. This way we may re-use the server for many different repositories.
The Unit tests consists of trying to clone two different Github repos. One is a proper repo and other a non-existing one. The first one should yield a success, the other one a failure. We check for success by making sure that a non-empty folder is created.
Compilation of the repository code is done by doing a cd to the test/ directory, followed by a:
mvn clean compile assembly:single
The output is then buffered and checked for a completed status text. If the parser finds that the compilation failed, an exception is thrown.
The Unit tests consists of trying to compile two different Github repos. One is a proper repo and other a non-existing one. The first one should yield a success, the other one a failure. We check for success by making sure that the compilation returns a success.
The testing of the repository is done by doing a cd to the test/ directory, followed by a:
mvn test
This will run the automated Unit tests, and a parses will check the output and decide whether all the tests completed successfully or not. If not, an exception is thrown.
The Unit test is a test trying to test a Github repo. The test checks whether the testing is run successfully, as well as if the tester class logs the testing statistics as expected.
Depending on the success or failure of the compilation and testing steps a commit status is sent to Github, through the Github API, as follows:
- Compilation failure: error
- Testing failure: failure
- Compilation success and testing success: success
The unit tests for updating commit status consist of one "code coverage" test, making sure the correct code is run when calling the function. The other test checks that it throws a NullpointerException for empty repository data (i.e. no previous setup).
To log and keep track of the previous builds a JSON file is used, which stores the states of the builds with additional information.
To access the full build information list, you will have to start the server and visit the following URL: http://localhost:8080/.