Report.md

@@ -111,9 +111,11 @@ We used Nunit to unit test what we could, but we couldn't find proper reference
 
 Original idea was to use C++ or Go for the gRPC programming, but after the gRPC was left solely to Kasper, he decided it would be best to use Node.js.
 
-gRPC was pretty much done after the first sprint. There has been updates to the protobuf message during these 5 sprints and updates have been made.
+gRPC was pretty much done after the first sprint, but it has been remade multiple times during the project to accomodate new way of sending data and what was needed in the database.
 
-Jest was used to unit test 78.7% of the code in gRPC.
+gRPC is running as a server on one of our salvaged PCs and every game view and even beacon scripts connect to it to get data needed to work together as a system.
+
+Jest was used to unit test over 80% of the code in gRPC.
 
 ### Bluetooth beacon
 
@@ -127,7 +129,11 @@ We were forced to use many different python 3rd party libraries to get all the f
 
 ### Gitlab CI
 
-We had Gitlab CI set up the way that it would run unit tests automatically with each push. Sonarscanner was also set up to run code analysis on each branch, as they were pushed
+Gitlab CI was set up so that when a programmer pushes his/her work the CI chain would automatically analyze the code, send it to sonarqube which checks the analyze against rulesets and sends a comment on the commit that tells what is wrong with code.
+
+Each component that has it's own branch has a .gitlab-ci.yml file, which holds all the commands needed for the CI chain to know what it is supposed to do.
+
+Sonarqube/scanner and unitesting are built as runners, that can be hosted on other servers. Gitlab needs to be public for Sonarqube to send comment to commit.
 
 ## Manuals for individual components