CSE 373, Spring 2019: GitLab Runners

[ PAGE UNDER CONSTRUCTION ]

Gitlab runners

Our GitLab repos will have runners set up to automatically check that the code in your repository compiles and passes checkstyle and that your tests pass. If everything is fine and all the tests pass, you'll get a green ✓ on your repo homepage; otherwise, you'll get a red ×. Check out this gif for a demo of how to find the runner's output in this case to see what went wrong.

Note that the runners will not be used during grading. They serve mainly as a sanity check (to make sure your code is pushed to GitLab properly) and as a benchmark for efficiency tests (the machine we use for grading should be more powerful than the ones the runners use, so you should aim to make your efficiency tests pass on the runners).

Additionally, the runner machines are shared with other courses, so we cannot guarantee that the test results are always accurate. In general, they tend to run slower towards deadlines, when everyone is pushing their code, so we recommend that you start early if you wish to make full use of the runners. This also means that you should NOT depend on the runners instead of running tests or Checkstyle locally.

If functionality tests sometimes fail on the runners, but consistently pass locally (and you've correctly pushed all your code to the runners), it's safe to assume that your code is fine and that the runners just are running slowly. However, if efficiency tests sometimes fail on the runners, you may want to consider optimizing your code.

Also, the runners will only check your code if you push a commit that changes your code; changes to other files will not trigger the runners, which means you will not see a ✓ or ×.