Skip to content

Common issues

In the following, we will bundle some common issues and how to resolve them.

Report Quality Standards

Your report is a critical part of the assignment evaluation. Many students submitted reports that lacked proper formatting, structure, or sufficient detail. A good report should meet the following standards:

1. Use proper Markdown formatting

  • Headers to structure your content (use #, ##, ###)
  • Code blocks for YAML/commands/configuration (use triple backticks: ```)
  • Inline code for commands, variables, file names (use single backticks: `)
  • Lists for multiple items (use - or 1.)
  • Bold/italic for emphasis

A well-formatted report is easier to read and shows you put effort into your work. See the GitLab markdown guide for more information.

2. Include the report body in the GitLab issue itself

Do not provide your report as a downloadable file (.docx, .pdf, .txt). Write the report directly in the GitLab issue description using Markdown formatting. This makes it easier to read and comment on.

3. Document your problem-solving process

Your report should not just list what you did, but also show how you solved problems:

  • What issues did you encounter?
  • What steps did you take to diagnose the problem?
  • How did you resolve it?
  • Include links to specific pipeline runs that demonstrate the problem or solution

Insufficient: "See commit history for changes" or "I added caching and it works now"

Good: "Initially, the pipeline was downloading dependencies every time (see pipeline #123). I added caching to the .m2/repository folder with key $CI_COMMIT_REF_SLUG. After this change (pipeline #124), the build time decreased from 3 minutes to 45 seconds."

4. Add required tags to your issues

Always add the requested tags to your report issues:

  • Report tag for all reports
  • Lab1, Lab2, etc. for the specific lab
  • Any other tags mentioned in the assignment

Tags help organize issues and make it easier to find your submissions.

5. Answer all questions thoroughly

If the assignment includes questions:

  • Don't just quote the lab documentation - show understanding with your own explanations
  • Include key pointers from lectures and course materials
  • Provide specific examples from your own implementation
  • Answer all parts of multi-part questions

Insufficient: "Artifacts are files that are passed between jobs."

Good: "Artifacts are files that are passed between jobs and stages in a pipeline. In our case, we use artifacts to pass the compiled .jar files from the maven-build job to the maven-docker-generation job. This avoids having to recompile the code. Artifacts are stored in GitLab and can be downloaded from the pipeline overview. We set an expiration time of 1 hour because we don't need them for releases, only for the current pipeline run."

6. Be concise but thorough

Your report can be brief, but it should not be too brief:

  • Explain your reasoning and thought process
  • Show evidence of problem-solving
  • Demonstrate understanding of concepts

A one-paragraph report with no details, no problem documentation, and no thought process is insufficient.

Examples of problematic reports

  • Very brief with no problem documentation
  • No markdown formatting (walls of plain text)
  • Questions not answered or only partially answered
  • Report provided as downloadable file instead of in issue description
  • Missing required tags
  • Referring to commit history instead of documenting issues and solutions
  • Direct quotes from documentation without demonstrating understanding

Maven wrapper script not executable

Many groups have run into issues with the ./mvnw script not being executable, resulting in Permission denied errors. To reliably add a file as executable on both windows and linux, you can use the following command:

git add --chmod=+x ./mvnw

This will add the file as executable in the git repository, and when you clone the repository on another machine, the file will still be executable. This way you won't have to start every job script with chmod +x ./mvnw.

Docker Hub rate limiting

Docker Hub has introduced rate limiting for anonymous users. This means that if you are not logged in, you can only pull a limited amount of images per 6 hours. This causes problems when building the logic service image using jib, as the base image eclipse-temurin is pulled directly from Docker Hub.

To avoid this issue you can use the eclipse-temurin image hosted on our public GitLab registry instead. To do this, change the base image in application.properties to:

quarkus.jib.base-jvm-image=gitlab.stud.atlantis.ugent.be:5050/utils/docker/eclipse-temurin:25-jre