Solved issue #4

Issue #4 -feat: Added version of dependencies to README (including Java version)

README.md

@@ -1,6 +1,13 @@
 # CI
 This project is an implementation of a small continuous integration server for Java projects built with `gradle`, working with webhooks. It supports compilation, testing and notification of results using commit status. It also features a history of the past builds, which persists even if the server is reloaded.
 
+### Dependencies
+This project runs with the following versions.
+- Java `20.0.2`
+- Gradle `8.4`
+- Ngrok `3.6.0`
+
+
 ## Run instructions
 The server can be run locally, but it must be accessible from the internet. We can use `ngrok` for that, which is an utility for tunneling incoming requests from an accessible domain to our machine. 
 
@@ -70,27 +77,33 @@ You're done ! Upon reception of each webhook, the CI server will clone the repos
 
 If the repository is private, the machine which hosts the server must have the corresponding authorizations. 
 
+### Authorizing the server to set commit statuses
+The server required a fine-grained personal access token with write permissions for commit statuses in a repository in order to set commit statuses with the results of the CI server. In order to authorize the server to set commit statuses do the following.
+1. Create a fine-grained personal access token with commit status write permissions to the repo ([tutorial](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)).
+2. Add the token to the `setCommitStatus()` method in `src/main/java/se/kth/ci/CIServer.java`.
+
 ### Test the project
 If you want to run all unit tests, then use the following command.
 ```shell=
 ./gradlew test
 ```
+Every method of the `se.kth.CI.CIServer` class is unit-tested. The method `parseResponse()` retreives information that is needed to clone and build a repository such as the URL and branch name. It is tested to ensure that it cannot parse non-JSON requests and that it has the correct behavior. The method `cloneRepository()` is implemented by excuting a Github repository cloning command from the program. It is tested using a test repository hosted by Rickard Cornell. The test ensures that the method only clones repositories with a valid URL and a valid branch name. For core feature n°1, the method `triggerBuild()` is also implemented by executing a build command. It is tested using one positive test and one negative test, which both use simplistic `gradle` projects in the test resources. For core feature n°2, the method `triggerTesting()` is implemented by executing the gradle test command shown above. It is tested using one positive and one negative test, making use of simplisic `gradle` projects in test resources as well. There also is a test for a repo that doesn't contain any test sources. The core feature n°3 is implemented by setting the commit status for a commit with the results of the CI server. This is done by executing the following command with the variables switched out to the appropiate values.
 
-Every method of the `se.kth.CI.CIServer` class is unit-tested. The method `parseResponse()` retreives information that is needed to clone and build a repository such as the URL and branch name. It is tested to ensure that it cannot parse non-JSON requests and that it has the correct behavior. The method `cloneRepository()` is implemented by excuting a Github repository cloning command from the program. It is tested using a test repository hosted by Rickard Cornell. The test ensures that the method only clones repositories with a valid URL and a valid branch name. For core feature n°1, the method `triggerBuild()` is also implemented by executing a build command. It is tested using one positive test and one negative test, which both use simplistic `gradle` projects in the test resources. For core feature n°2, the method `triggerTesting()` is implemented by executing the gradle test command shown above. It is tested using one positive and one negative test, making use of simplisic `gradle` projects in test resources as well. There also is a test for a repo that doesn't contain any test sources. Core feature n°3 is implemented by setting the commit status for a commit with the results of the CI server. This is done by calling the following command with the variables switched out to the appropiate values:
 ```shell=
 curl -Li \
   -X POST \
   -H "Accept: application/vnd.github+json" \
   -H "Authorization: Bearer <YOUR-TOKEN>" \
   -H "X-GitHub-Api-Version: 2022-11-28" \
   https://api.github.com/repos/OWNER/REPO/statuses/SHA \
-  -d '{"state":<state>,"context":<context>,"description":<description>}'
+  -d '{
+          "state":<state>,
+          "context":<context>,
+          "description":<description>
+      }'
 ```
 The testing is implemented by changing the commit status of a commit on the test repository hosted by Rickard Cornell.  
 
-For the P+ feature, an sqlite database was implemented to save build inforamtaion such as commit_id, timestamp and the build log. Then we implemented handling of get requests to the server so that upon searching the URL, the server fetches the corresponding build(s) from the database. 
-
-URL: 
 
 ### Generate documentation
 If you want to generate documentation as HTML, then use the following command. 
@@ -100,6 +113,9 @@ If you want to generate documentation as HTML, then use the following command.
 This will generate all needed components in the `/build/docs` subdirectory of your working directory. Open `index.html` in the browser of your choice to navigate through the docs. 
 
 ### Access build logs
+
+For the P+ feature, an `sqlite` database was implemented to save build information such as `commitId`, `timestamp` and the `buildLog`. Then we implemented handling of GET requests to the server so that upon searching the URL, the server fetches the corresponding build(s) from the database. 
+
 #### Display all build history
 In order to display the whole build history, follow the next steps.
 1. Open up your web browser