Task: Add step to pipeline to trigger the versioning script.

Currently, when lastSubmission is reset for all users, the first login can be very slow in the case where a user has a lot of codeforces submissions, or simply if the codeforces API is being slow. We don't want to be so tightly dependant on their API's load time for our basic flow.

Ideas for fixing this:

• Separate log-in and update-user-submissions into two separate routes
  • Currently, both of these functionalities are done in a single route, so the UI can't continue with the user data until the submissions are updated and the request has returned

Allow admins to create custom problems in WISP, and these problems would be run on our own Online Judge against a custom test suite.

Could be implemented with a separate microservice that spins up a thread to run the test in a sandbox (using something like this library to sandbox?)

Research how to setup a mailing server to know if we need a full mailing microservice or if it can just be a feature in the users microservice.

Check how HackMcGill does it, could be a good inspiration.

Similarly to vJudge, look into a system that submits to codeforces without the user having to manually navigate to the submission.

Testing the entire functionality of the application.

@ahmed-elehwany 's specialty.

When committing code that can not automatically be fixed by npm run format, husky should cancel the commit in a pre-commit hook. However, currently the commit is still allowed to go through.

This has been observed in wisp-problems-microservice, but probably applies to all services using husky.

Look into and implement a package to manage our versioning/releases for each repo.

Something like this package. Although do some more research, there may be better options.

Need to dockerize the e2e tests environment, before we can support CI test step.

Commits are being pushed without being linted, and it's annoying for the developers to have to run lint every time. We should add lint commands to the git precommit hooks on each repo.

Currently:

• wisp-ui linting step both checks linting and makes linting changes?
• wisp-problems-microservice and wisp-problems-microservice linters aren't fully set up and configured?

What we want:

• pre-lint hook before each commit to check linting + make linting changes.
• CI action to ONLY check linting (don't make linting changes), and fail the build if linting isn't good.

The problems microservice docs are incomplete as routes such as DELETE problems/problemSets aren't shown. Style them as we did with the users section of the docs.

In cases where something breaks with an individual user's problem tracking (as has happened a few times already), we want an easy way to fix this. This comes in the form of allowing users to reset their lastSubmission value, forcing the API to refresh their information from codeforces.

Two parts to this:

• users-microservice: add a route that allows a user to reset only their own lastSubmission
• UI: add a button (on the user's profile? or on the dashboard?) that calls this route

We're starting to have a lot of events that require contacting other microservices. Currently, we're writing custom endpoints for this. Eventually we might want to set up an event system to handle these, rather than making direct calls.

Todo:

• Research whether we want to use pub-sub, or continue direct calls to a defined interface (gRPC-like)

Interactions that would require pub-sub (please keep this up to date):

• resetLastSubmission in the users' microservice when a new problemset is created
• deleting problemset => also delete ID in user model
• the mailing microservice?

The current config for our pods doesn't request any resources (cpu/ram) nor does it set any limits. This can be dangerous as some pods can use up more resources than anticipated and deprive others. Resource requests will ensure all our pods have the resources they need while resource limits will terminate pods when they consume more than they should.

Flesh out the central repo's README with infos such as:

• links to other repos
• mkdocs command to update the deployed docs website

Backend repositories need unit testing.

TODO:

• Set up unit testing framework/environment on:
  • wisp-users-microservice
  • wisp-problems-microservice
• Write full unit tests on:
  • wisp-users-microservice
  • wisp-problems-microservice

Currently, 422 errors are thrown in validators, and 400 errors in controllers. However, we might want to factor out 400 errors to a separate middleware, or include it in the existing validators.

Furthermore, in the user's microservice we check for existence of a conflicting username in the controller, with a 400 error. However, in the problems microservice, we check for the existence of problems/problemsets in the validators, returning 422 responses. These are similar validation checks, but they occur in different parts of the code and return different responses. This should be standardized/refactored.

Describe the bug
Mongo connection times out when attempting to run the docker compose under build

To Reproduce
Steps to reproduce the behavior:

1. Open build in terminal
2. Run docker-compose up
3. Wait 30 seconds
4. See error

Fix incoming - this happens because no path is specified after the database path (i.e. we need to specify mongodb://mongo:27017/wisp or something as opposed to mongodb://mongo:27017/)

Need to create swagger specs to more explicitly and clearly define API endpoints.

Swagger needed for:

• wisp-problems-microservice
• wisp-users-microservice

E2E framework has been set up (thank you @ahmed-elehwany ). Now we just need to actually write the tests!

Should wait until #23 is done

See title. @ValerianClerc and @MohamedBeydoun to meet soon to discuss what will go on here.

Templates for:

• bug
• feature request
• pull request template

Currently, we store our kubernetes config in the wisp-kube repo. This causes a few issues:

• K8s config changes have to be added in a separate PR to a different repo than the project that the dev is working on
• Repeated config for different environments (currently, dev and prod have nearly the same configuration except for the namespace)

It would be helpful to move our kubernetes config into charts within their respective repo to solve these issues.

Add support for profile pictures for users. Backend User model already has the profilePhoto string.

TODO:

• Profile photo upload and display on the frontend
• Set up some sort of GCP storage or S3 bucket to hold and serve the profile photos

In order to improve resilience when updating our services, we can make use of the kubernetes resource "Pod Disruption Budget" oe PDB (https://kubernetes.io/docs/tasks/run-application/configure-pdb/) to limit the number of downed pods in cases of voluntary disruptions (updates, accidentally deleting pods and deployments, ...).

We want to be able to toggle PDBs for production deployments only so make use of the logic helm offers in our charts (we don't want them for dev since they're useless when we only have one pod running per deployment).

liveness and readiness probes can be used to avoid directing trafic to pods that aren't ready (and kill pods if necessary)

see:
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

Add lifecycle prestop hooks to our pods in order for them to better handle being terminated e.g. nginx doesn't gracefully shutdown when the pod is terminating, so requests that were sent before the termination signal will fail -> a prestop hook would belp gracefully shutdown nginx before stopping the container so the remaining requests can be properly handled.

A new service to manage news and announcements.

Stories:

• Microservice
• UI

Clean up central wisp repo as a summary of the whole project, make it look nicer. Maybe with this.

Also can improve the other microservice READMEs to show things like code coverage, etc.

Pipeline in all repos should have testing steps before the current steps. Testing can be added to our github actions.

Add dependabot to all our projects to keep our packages up to date.

New feature: similar to problemSets, but these are only active for a defined period of time. Once that time is over, a leaderboard is visible to see how users performed.

Once they're done, these contests will be publicly archived, and will be completable by users on their own time, similarly to problemSets

The hashed problemId should be more specific to not confuse with the problem's _id. Could be like generatedProblemId or problemIdHash.

Two parts:

• Update wisp-problems-microservice
• Update wisp-ui

Add a leaderboard to see all users and their progress.

This requires:

• modifying the user model to store user scores
• adding a page to the UI to see the leaderboards

Note: this issue also goes well with the addition of viewing other users' profile pages, so that you can click on them in the leaderboard and see their page.