Dockerisation of RepoSense

[georgetayqy]

What feature(s) would you like to see in RepoSense

Currently, we are facing issues regarding the standardisation of tests for both the frontend and backend.

Considering that there is a wide range of possible combinations of dependencies that need to be tested to ensure a consistent look and performance across all platforms, the use of a containerisation framework such as Docker would help accelerate our current workflows and increase the overall coverage of our tests.

Moreover, Docker provides us with a new way to help our users who are facing dependency issues, since the dependencies and codebase are bundled and abstracted away from the user, who just needs to use Docker to run RepoSense without worrying if the dependencies would cause issues for them.

This would also allow us to more confidently upgrade our existing dependencies while providing support for older dependencies through older, backwards-compatible builds of RepoSense.

For the more tech-savvy users or admins, the introduction of Docker containers provides them with a way to use other container orchestration tools such as Kubernetes to better manage multiple running instances of RepoSense on their cloud/web services, increasing the overall availability of RepoSense for their target users.

Docker integrates nicely with Github Actions (more here) and can be easily orchestrated using Docker Compose, allowing us to create multiple Docker containers and store them on Github Packages or Docker Hub, or to use it for mainly testing purposes using Github Actions.

There are also ways for the Docker CLI to accept new parameters at the CLI during execution and to pass them to the Docker container, mimicking how our existing CLI commands work. We can also mount a user's local file system into the Docker container so that they can view and analyse any other local repositories on their local file system, maintaining RepoSense's key selling points and features.

Is the feature request related to a problem?

The use of Docker might help resolve current issues related to frontend and backend testing issues, as well as issues related to dependency clashes.

If possible, describe the solution

We could look into integrating Docker into our codebase and workflows, by creating Dockerfiles and docker-compose files, and experiment with how we can most efficiently pass in parameters from the Docker CLI into the Docker containers, as well as how we can mount our local file systems into the Docker containers we create and run.

If applicable, describe alternatives you've considered

This feature might prove to be another dependency that we need to resolve now since we have to ensure that the Docker containers we generate and upload would be the most up-to-date version and that there could be multiple Docker containers at any time with differing dependencies for different user groups.

This might prove to be more cumbersome than leaving things as it is right now.

Additional context

N/A

[sopa301]

As discussed, this is not the first time Docker has been introduced to the NUS-OSS ecosystem. Given that RepoSense is an on-premise system, it makes much more sense to introduce Docker here compared to TEAMMATES. It's not as if the current Java jar system is overly troublesome, but it could reduce the odds of unexpected OS-specific or version-specific issues from popping up.

The bigger issue would be the learning curve to picking Docker up. As this is an open source project targeted towards student contributors, we would need to ensure the difficulty of running a Docker setup locally is as difficult as running the Java system currently. This can be achieved with a proper guide. Also, we should abstract the Docker details so that newcomers won't be confused.

Another issue would be continuity. This would add another key technology to maintain, so each batch of RepoSense developers would need a person with knowledge of Docker. From what we discussed, it seems the basic Docker script to generate the executable/image won't be too complex for newcomers, but we should be mindful regardless.

[georgetayqy]

I am currently looking into just Ubuntu/Linux distros for now as the testing bed for the new Docker changes.

The results are looking promising so far, however, there are some challenges that I have faced so far:

• Running Gradle's systemTest after test seems to cause something to break, so for now I am using build instead to test if RepoSense will compile
• MacOS do not offer Docker containers of the OS, and a 3rd party image Docker-OSX is being explored as a replacement for it (though I am also having some issues regarding that too (trying to copy over RepoSense and having it execute in the MacOS container, downloading brew and nvm, etc.)
• I cannot test Windows containers directly since M1 macs are not supported (only x86 chips are supported, which shouldn't be much of a problem since Github's runners are x86)

Will keep everyone posted about the updates via this thread.

[georgetayqy]

I have created a separate repository that creates Ubuntu 20.04 and 22.04 images every week, pushing it onto Docker Hub where anyone can pull it for use.

The repository where the scheduled action is taking place is here while the public Docker Hub repository is here.

These images are used as base images for the Docker test containers that we will build during CI in the main repository.

[georgetayqy]

As discussed, there is minimal benefit that Docker might offer in terms of optimising our current testing/deployment workflow. As such, we are abandoning the use of Docker and updating Github Actions instead to make it more robust for different versions of Java and Node.