1. Why Slow Pipelines? What to do?

It is likely that the GitLab Runners (CI pipelines) will be slow near the due date of an assignment.

Pipelines are conveniences, NOT necessities. It's normal to have issues with pipelines failing or being slow in both COMP2511 and real world applications (software systems are imperfect). While 95% of the time pipeline jobs run within a few seconds to a few hours, later in term and especially around deadlines, we find Gitlab pipelines start to slow down simply due a heavy load against limited resources resulting in more pending, incomplete, and disrupted pipelines.

This should NOT block your development work as you can run anything the runner does locally on VLAB and have confidence that it will pass the pipeline 🥳🎉 This is because VLAB or any CSE machine is the closest to the pipeline environment.

2. How do you merge without pipelines?

If you are confident that your code is correct and you have tested it locally, you can merge your branch without waiting for the pipeline to pass.

You can do this by following the screenshot and clicking Merge Immediately:

3. How can you guarantee your code is manually correct?

The continuous integration (CI) pipelines exist to test your code in a predictable environment. We need to recreate this predictability.

1. Ensure the branch you are merging into main is up to date with main. You can do so by running the following commands:

git checkout main
git pull origin main
git checkout <your-branch>
git merge main

2. Remove any non-committed files (basically any files that are in .gitignore). We want to get rid of any build artifacts and ensure it is a "clean clone" of the repository on your branch. You can do so by running the following command:

git clean -fxd

If you would like to exclude a file from being removed, you can do so by adding the -e file_name flag to it, for example:

git clean -fxd -e .env

3. Run the tests locally. You can find what commands you need to run in the .gitlab-ci.yml file in the root of your repository. They generally should be:

• gradle compile: to check compilation
• gradle test: to run your tests
• gradle coverage: to check your test coverage & that it passes the minimum
• You can also follow the dryrun commands to test if you pass the dryruns. Note that the dryrun part of the CI pipeline simply just replaces your test files with the original test files given, or the ones found in the '.zip' folder linked in the specification.

4. If everything has passed, you can push your changes to your branch on GitLab and merge it immediately.

3.1. Why does this work?

The CI pipeline runs the same commands as you do locally. The only difference is that it runs it in a clean environment, ensuring that your code is correct and that it doesn't rely on any local files or configurations.

We also want to make sure that any new changes in main that aren't in your current branch are merged into your branch. This is to ensure that your code works with the latest changes in the repository. A common problem that can occur is when your pipeline & tests will pass on the branch, but once it has been merged into main, it will fail due to the combined changes. This is very rare, however, it is possible.