Run Jobs without internet
Dealing with internet-less jobs
As previously stated, containers ran in MaaS do not have access to the internet. This means that you will have to resort to alternate strategies whenever your toolchain wants to access the internet.
Strategies with common toolchains
This section lists a few workable strategies with common toolchains.
The goal here isn't to provide you with a full example but to point you in a direction that may work for you specific use case.
If you found a good strategy that isn't listed here, please consider contributing it to this documentation by clicking the "edit this page" link at the bottom of this page, thanks!
NodeJS with NPM/Yarn/PNPM
Run npm install, yarn or pnpm install when building your Docker image.
.NET Core or .NET 5+ with dotnet
Run dotnet restore when building your Docker image.
C/C++
Use the system packager (e.g. apt-get on Debian-based) to download required
dependencies when building your Docker image.
Storing files in Testsuite vs Docker image
You have to choose between storing information about individual assignments (e.g. the tests for that assignment) in the testsuite tarball or in the Docker image.
Storing in tarballs?
As previously stated, the testsuite tarball is concatenated to the student's submission. This means that, for every submission made by each student, the input tarball (student submission + testsuite) is sent to the central storage service. Heavy tarballs lead to heavy load on this critical service, which can slow down and impact all operations.
Storing in Docker images?
Storing data in Docker images means having 1 image per assignment. Each image is pulled on each worker when required, meaning that, if you have a lot of assignments, pipelines will require pulling a lot of images which can take a lot of storage space on MaaS workers.
Moreover, complex Docker images will lead to excessive build times on your end since, when you will need to rebuild your Docker images, you will need to do so for each assignment.
So... What do I choose?
In 90% of cases, the recommended strategy is to store test data in the testsuite.
Put as much data that you need in all assignments as possible in the Docker image. For example, if you always use the same unit testing framework, put it in the Docker image.
Store test cases, unit test data, etc. in the testsuite tar.
However, if a few assignments require complex system dependencies or heavy test data (> 20 MB), you should probably create a Docker image for said assignments.
If you are unsure of what to choose, do not hesitate to contact us. We will establish the best strategy for your case.