DD2480-Assignment-2-CI

This is a simple CI server for the Assignment #2: Continuous Integration which when receiving a webhook from github checks out the commit, runs mvn compile and mvn test and then sends a status notification to the GitHub commit in question.

Setting up the project

• Make sure to have java openjdk 21 installed
• Make sure you have ngrok installed
• Make sure you have the latest version of maven installed
• Create a GitHub fine-grain Personal Access Token for the repo with only permission for "Read and Write access to commit statuses" and "Read access to metadata".
• Create a plain text file named "githubPAT" in the root folder of the project and copy the token into the file. This is required for authenticating the status updates.

Running the project

• Clone the repo and make sure you are inside the CI subfolder
• Run mvn test to confirm that everything is working, the "githubPAT" file mentioned above is required before making this step.
• Run the program using intellij or VSCode or using the run command
• on a seperate terminal run ngrok http 8080

For more details on setting up the server with webhooks look here

Documentation

• To generate JavaDoc HTML files run mvn javadoc:javadoc. The documentation is found under target/site/apidocs

CI feature #1 - compilation

Implementation

To compile the code, the code uses the Compiler Class. This class runs Maven with the aide of ProcessBuilder. To make sure it runs correctly, the program also takes as an input of the file path to ensure that the correct branch is to be used in the process. It then simply runs mvn compile to compile the code within this branch. While the program compiles, the code saves the results of the compilation in compile_results.txt, which we are then assessing to find BUILD SUCCESS for a successful compilation.

Testing

To test this successfully, we have created two different branches. The first one compiles successfully, whereas the second does not. To test the program, we are then running the compilation function on said branches to see whether the two branches yield the correct result for a successful or unsuccessful compilation.

CI feature #2 - testing

Implementation

To test the program, the code calls maven with the ProcessBuilder class. The function then takes as an input parameter the specific test case, a specific test class or - if the input is empty - all tests. After these tests are run, another function will check a file where the ersults are stored to check whether the tests passed by checking for BUILD SUCCESS in this file. The code then returns the boolean evaluation of said test, or will throw an exception if the test fails.

Testing

The testing process of this function is done with the aide of dummy tests. These dummy tests have one true assertion and one false assertion. We then run specific test cases for these dummy tests to see if the function also returns the correct assertions.

CI feature #3 - notification

Implementation

The status notification (found in StatusNotification) is implemented using curl POST request which is executed by java RunTime.

The request consists of:

• The API path consisting of the repo, the owner and the full 40 character SHA.
• A GitHub PAT for authentication.
• A JSON object body with a state, target_url, description, and context field. This message is in turn generated by the createStatusMessage function, which takes in the outcome of the compilation and test suit.

Testing

The test suit for createStatusMessage consists of assuring that the content of the JSON message is correct for the combinations: both compilation and tests passes, compilation passes and tests fails and compilation fails.

The test suit for statusNotification consists of a check that the GitHub PAT exists, as well as that a succesfull commit returns success, a failing commit returns failure and that an incorrect PATH (incorrect SHA) results in state not being found.

Team evaluation

For seeding we achieve all of the relevant bullet points with the exception of governance and leadership structure. With regards to forming we fulfil basically all of them to some extent, with the exception of external collaborators. On the collaboration front we achieve some of the, specifically the communication and focus while the "working as one unit" and knowing each other well is more arguable. For performing we are adapting to and identifying problems while we might struggle a bit more with time commitments, not duplicating work and not backtracking. Finally adjourning does not seem relevant as we are not in that stage of the process.

Statement of contribution

Mert Demirsü - Worked on implementing server communication in regards to compile & Parse and JUnit Tests. Mixed work occured with both alone and pair programming in Group.

Melissa Mazura - My contributions consisted of sucessfully completing the CI feature Testing. I have created a class that will run tests, save the results to a separate file and then check whether all tests succeeded. I had problems getting Maven to run, but in the end I believe that my contribution to the project has been positive.

Marcus Odin - I worked on getting the server to pull the commit in question, both alone and as pair programming. While doing this I also experienced the difficulities of integration since it was one of the later festures made that was also communicating with other parts of the code. Also reviewed pull requests.

Atheer Salim - I worked on setting up the basic code skeleton for the project with maven. I worked on parsing the json request that comes from the webhook request by github. I also integrated everyone else code together. I think I have contributed greatly to the project and I have understood in practice how a CI server works.

Jonatan Tuvstedt - I have primarily focused on issue #7, implementing the commit status notification to GitHub. This has gone very well and I am proud of this valuable contribution, as I had not worked with the GitHub REST API before, nor used http calls in any large extent. I also worked on finalising issue #4, cloning the repo.