Skip to content

docs: add remarkable note in readme #148

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
djonte merged 1 commit into from
Feb 11, 2026
Merged

docs: add remarkable note in readme #148

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -91,6 +91,9 @@ The obstacles to reach the next state consists of two things. One is that we nee

## Statement of Contributions

**We are particularly proud of our concurrent handling**
In this project we have worked together and faced many difficult challenges, everything from endless merge conflicts (as the contributions were often overlapping in nature) to integration with the Github API. In this project we take pride over our work. Something that we are especially proud of and feel is remarkable is our implementation of concurrent handling of incoming requests. In this, the server can seamlessly build and test several different commits at the same time. This works by creating a separate testing directory for each incoming request, differentiating commits by their SHA identifier, and then building and testing the respective builds at the same time.

### [Elias Richard Næss] — GitHub: [@daDevBoat]
Elias was responsible for the implementation of the usage of the Github commit REST API, implementing a testing structure that allowed for the server being able to concurrently handle requests, implementing validatePushEvent and validateRepoName functions, and made the CiService detach and run asynchronously such that the webhook gets a 202 message returned once payload is recieved and validated and the building and testing is handled by a seperate thread.

Expand Down