Merge branch 'develop' into feature/exam-mode/generate-missing-studen…

…t-exams-on-demand

.github/workflows/check-translation-keys.yml

@@ -18,7 +18,4 @@ jobs:
         with:
           python-version: "3.12"
       - name: Check if translation keys match
-        run: >
-          python .ci/translation-file-checker/translation_file_checker.py
-            --german-files src/main/webapp/i18n/de/
-            --english-files src/main/webapp/i18n/en/
+        run: python .ci/translation-file-checker/translation_file_checker.py --german-files src/main/webapp/i18n/de/ --english-files src/main/webapp/i18n/en/

.github/workflows/validate-pr-title.yml

@@ -0,0 +1,14 @@
+name: Validate PR Title
+
+on:
+  pull_request:
+    types: [opened, synchronize, reopened, ready_for_review, edited]
+
+jobs:
+  validate-pr-title:
+    runs-on: ubuntu-latest
+    timeout-minutes: 1
+    steps:
+      - uses: Slashgear/[email protected]
+        with:
+          regexp: '^`(Programming exercises|Integrated code lifecycle|Quiz exercises|Modeling exercises|Text exercises|File upload exercises|Exam mode|Grading|Assessment|Communication|Notifications|Team exercises|Lectures|Integrated markdown editor|Plagiarism checks|Learning analytics|Adaptive learning|Learning path|Tutorial groups|Iris|Scalability|Usability|Performance|Infrastructure|Mobile apps|Development|General)`:\s[A-Z].*$'

README.md

@@ -193,7 +193,7 @@ Refer to [Using JHipster in production](http://www.jhipster.tech/production) for
 The following command can automate the deployment to a server. The example shows the deployment to the main Artemis test server (which runs a virtual machine):
 
 ```shell
-./artemis-server-cli deploy [email protected] -w build/libs/Artemis-7.5.6.war
+./artemis-server-cli deploy [email protected] -w build/libs/Artemis-7.6.0.war
 ```
 
 ## Architecture

angular.json

@@ -113,7 +113,7 @@
               },
               {
                 "glob": "**/*",
-                "input": "./node_modules/monaco-editor/min/vs",
+                "input": "./node_modules/monaco-editor/bundles/vs",
                 "output": "vs"
               }
             ],

build.gradle

@@ -25,7 +25,7 @@ plugins {
 }
 
 group = "de.tum.cit.aet.artemis"
-version = "7.5.6"
+version = "7.6.0"
 description = "Interactive Learning with Individual Feedback"
 
 java {
@@ -246,12 +246,15 @@ dependencies {
     implementation "org.gitlab4j:gitlab4j-api:6.0.0-rc.5"
 
     implementation "de.jplag:jplag:${jplag_version}"
-    implementation "de.jplag:java:${jplag_version}"
-    implementation "de.jplag:kotlin:${jplag_version}"
+
     implementation "de.jplag:c:${jplag_version}"
-    implementation "de.jplag:swift:${jplag_version}"
     implementation "de.jplag:java:${jplag_version}"
+    implementation "de.jplag:javascript:${jplag_version}"
+    implementation "de.jplag:kotlin:${jplag_version}"
     implementation "de.jplag:python-3:${jplag_version}"
+    implementation "de.jplag:rlang:${jplag_version}"
+    implementation "de.jplag:rust:${jplag_version}"
+    implementation "de.jplag:swift:${jplag_version}"
     implementation "de.jplag:text:${jplag_version}"
 
     // those are transitive dependencies of JPlag Text --> Stanford NLP
@@ -270,7 +273,7 @@ dependencies {
         }
     }
 
-    implementation "org.apache.logging.log4j:log4j-to-slf4j:2.24.0"
+    implementation "org.apache.logging.log4j:log4j-to-slf4j:2.24.1"
 
     // Note: spring-security-lti13 does not work with jakarta yet, so we built our own custom version and declare its transitive dependencies below
     // implementation "uk.ac.ox.ctl:spring-security-lti13:0.1.11"
@@ -342,7 +345,7 @@ dependencies {
 
     implementation "tech.jhipster:jhipster-framework:${jhipster_dependencies_version}"
     implementation "org.springframework.boot:spring-boot-starter-cache:${spring_boot_version}"
-    implementation "io.micrometer:micrometer-registry-prometheus:1.13.4"
+    implementation "io.micrometer:micrometer-registry-prometheus:1.13.5"
     implementation "net.logstash.logback:logstash-logback-encoder:8.0"
 
     // Defines low-level streaming API, and includes JSON-specific implementations
@@ -405,7 +408,7 @@ dependencies {
     implementation "org.springframework.cloud:spring-cloud-starter-config:4.1.3"
     implementation "org.springframework.cloud:spring-cloud-commons:4.1.4"
 
-    implementation "io.netty:netty-all:4.1.113.Final"
+    implementation "io.netty:netty-all:4.1.114.Final"
     implementation "io.projectreactor.netty:reactor-netty:1.1.22"
     implementation "org.springframework:spring-messaging:6.1.13"
     implementation "org.springframework.retry:spring-retry:2.0.9"
@@ -416,7 +419,7 @@ dependencies {
     implementation "org.springframework.security:spring-security-oauth2-core:${spring_security_version}"
     implementation "org.springframework.security:spring-security-oauth2-client:${spring_security_version}"
     // use newest version of nimbus-jose-jwt to avoid security issues through outdated dependencies
-    implementation "com.nimbusds:nimbus-jose-jwt:9.41.1"
+    implementation "com.nimbusds:nimbus-jose-jwt:9.41.2"
 
     implementation "org.springframework.security:spring-security-oauth2-jose:${spring_security_version}"
     implementation "org.springframework.security:spring-security-crypto:${spring_security_version}"
@@ -464,7 +467,7 @@ dependencies {
     implementation "com.google.code.gson:gson:2.11.0"
 
 
-    implementation "com.google.errorprone:error_prone_annotations:2.32.0"
+    implementation "com.google.errorprone:error_prone_annotations:2.33.0"
 
     // NOTE: we want to keep the same unique version for all configurations, implementation and annotationProcessor
     implementation("net.bytebuddy:byte-buddy") {
@@ -528,11 +531,11 @@ dependencies {
     testImplementation "org.mockito:mockito-core:${mockito_version}"
     testImplementation "org.mockito:mockito-junit-jupiter:${mockito_version}"
 
-    testImplementation "io.github.classgraph:classgraph:4.8.176"
+    testImplementation "io.github.classgraph:classgraph:4.8.177"
     testImplementation "org.awaitility:awaitility:4.2.2"
     testImplementation "org.apache.maven.shared:maven-invoker:3.3.0"
     testImplementation "org.gradle:gradle-tooling-api:8.10.2"
-    testImplementation "org.apache.maven.surefire:surefire-report-parser:3.5.0"
+    testImplementation "org.apache.maven.surefire:surefire-report-parser:3.5.1"
     testImplementation "com.opencsv:opencsv:5.9"
     testImplementation("io.zonky.test:embedded-database-spring-test:2.5.1") {
         exclude group: "org.testcontainers", module: "mariadb"

docs/dev/guidelines/database.rst

@@ -295,7 +295,7 @@ Best Practices
         // IrisSubSettings.java
         @Column(name = "allowed_models")
         @Convert(converter = IrisModelListConverter.class)
-        private TreeSet<String> allowedModels = new TreeSet<>();
+        private TreeSet<String> allowedVariants = new TreeSet<>();
 
 
   * **Ordered Collection with duplicates**: When you want to order the collection of (potentially duplicated) objects of the relationship, then always use a ``List``. It is important to note here that there is no inherent order in a database table. One could argue that you can use the ``id`` field for the ordering, but there are edge cases where this can lead to problems. Therefore, for an ordered collection with duplicates, **always** annotate it with ``@OrderColumn``. An order column indicates to Hibernate that we want to order our collection based on a specific column of our data table. By default, the column name it expects is *tablenameS\_order*. For ordered collections, we also recommend that you annotate them with ``cascade = CascadeType.ALL`` and ``orphanRemoval = true``. E.g.:

docs/index.rst

@@ -37,6 +37,7 @@ All these exercises are supposed to be run either live in the lecture with insta
    user/grading
    user/courses/customizable
    user/markdown-support
+   user/integrated-code-lifecycle
    user/exports
    user/mobile-applications
    user/lti

docs/user/exercises/programming-exercise-features.inc

@@ -37,6 +37,8 @@ Instructors can still use those templates to generate programming exercises and
   +----------------------+----------+---------+
   | JavaScript           | yes      | yes     |
   +----------------------+----------+---------+
+  | R                    | yes      | yes     |
+  +----------------------+----------+---------+
 
 - Not all ``templates`` support the same feature set and supported features can also change depending on the continuous integration system setup.
   Depending on the feature set, some options might not be available during the creation of the programming exercise.
@@ -67,9 +69,11 @@ Instructors can still use those templates to generate programming exercises and
   +----------------------+----------------------+----------------------+---------------------+--------------+------------------------------------------+------------------------------+----------------------------+------------------------+
   | OCaml                | no                   | no                   | no                  | no           | n/a                                      | yes                          | no                         | L: yes, J: no          |
   +----------------------+----------------------+----------------------+---------------------+--------------+------------------------------------------+------------------------------+----------------------------+------------------------+
-  | Rust                 | no                   | no                   | no                  | no           | n/a                                      | no                           | no                         | L: yes, J: no          |
+  | Rust                 | no                   | no                   | yes                 | no           | n/a                                      | no                           | no                         | L: yes, J: no          |
+  +----------------------+----------------------+----------------------+---------------------+--------------+------------------------------------------+------------------------------+----------------------------+------------------------+
+  | JavaScript           | no                   | no                   | yes                 | no           | n/a                                      | no                           | no                         | L: yes, J: no          |
   +----------------------+----------------------+----------------------+---------------------+--------------+------------------------------------------+------------------------------+----------------------------+------------------------+
-  | JavaScript           | no                   | no                   | no                  | no           | n/a                                      | no                           | no                         | L: yes, J: no          |
+  | R                    | no                   | no                   | yes                 | no           | n/a                                      | no                           | no                         | L: yes, J: no          |
   +----------------------+----------------------+----------------------+---------------------+--------------+------------------------------------------+------------------------------+----------------------------+------------------------+
 
   - *Sequential Test Runs*: ``Artemis`` can generate a build plan which first executes structural and then behavioral tests. This feature can help students to better concentrate on the immediate challenge at hand.

docs/user/exercises/programming-repository-access.inc

@@ -1,3 +1,5 @@
+If you are a student, and want to know how to use the Artemis Version Control for checking out repositories locally, :ref:`checkout this guide.<local-vc>`
+
 The following tables lists the different types of repositories and gives an overview of the access rights different users have.
 To gain these access rights, a user must assume the indicated role in the course the repository belongs to.
 

docs/user/exercises/programming.rst

@@ -224,19 +224,5 @@ Each one represents a single test case feedback and should have the format:
 Integrated Code Lifecycle
 -------------------------
 
-The following sections describe programming exercise features that are part of the integrated code lifecycle system.
-
-Repository View
-^^^^^^^^^^^^^^^
-
-.. include:: programming-integrated-code-lifecycle-repository-view.inc
-
-Build Agent View
-^^^^^^^^^^^^^^^^
-
-.. include:: programming-integrated-code-lifecycle-build-agent-view.inc
-
-Build Overview View
-^^^^^^^^^^^^^^^^^^^
-
-.. include:: programming-integrated-code-lifecycle-build-queue-view.inc
+The Artemis Integrated Code Lifecycle system allows you to use programming exercises fully integrated within Artemis, without the need of any external tools.
+Find more information on it :ref:`here<integrated code lifecycle>`.

docs/user/icl/general.rst

@@ -0,0 +1,12 @@
+.. _icl-general-information:
+
+General Information
+===================
+
+Artemis offers the Integrated Code Lifecycle (ICL), a comprehensive feature designed to streamline the development process for programming exercises.
+ICL combines version control, secure communication, and continuous integration to provide a seamless experience for students and instructors.
+Understanding these components is crucial for effectively using Artemis, especially if you're new to concepts like SSH and Git. The key components of ICL are:
+
+- :ref:`Local Version Control<local-vc>`:         Use the Local Version Control to interact with the repositories of programming exercises.
+- :ref:`SSH<basic SSH introduction>`:             Use SSH to perform Git operations on repositories.
+- :ref:`Local Continuous Integration<local-ci>`:  Exercise submissions are built and tested by the Local CI system.

docs/user/exercises/programming-integrated-code-lifecycle-build-agent-view.inc → docs/user/icl/local-ci-build-agent-view.inc

@@ -5,7 +5,7 @@ The build agent view consists of two parts: the *Build Agent Summary View* and t
 The **Build Agent Summary View** shows a list of all build agents in the system, along with their status (idle and running), maximum number of concurrent builds, and running builds.
 The running builds can be canceled individually by clicking the red cancellation button next to the build. An Administrator can also cancel all running builds on a build agent by clicking the '*Cancel All*' button.
 
-.. figure:: programming/build-agent-summary.png
+.. figure:: local-ci/build-agent-summary.png
    :alt: Build Agent Summary View
    :align: center
 
@@ -20,7 +20,7 @@ the submission time, start time, end time, the duration of the build job, the co
 The administrator can click on the participation ID to navigate to the participation's submission page.
 The administrator can also click on the commit hash to navigate to the commits details page and the course ID to navigate to the course management page.
 
-.. figure:: programming/build-agent-details.png
+.. figure:: local-ci/build-agent-details.png
    :alt: Build Agent Details
    :align: center
 

docs/user/exercises/programming-integrated-code-lifecycle-build-queue-view.inc → docs/user/icl/local-ci-build-queue-view.inc

@@ -1,7 +1,7 @@
 Artemis provides a build overview view that displays all queued, running, and finished build jobs. Access to the system-wide build overview is
 exclusively available to **Administrators** through the *System Administration* menu.
 
-.. figure:: programming/buildQueueSystemAdministration.png
+.. figure:: local-ci/buildQueueSystemAdministration.png
    :alt: Build Overview System Administration
    :align: center
 
@@ -10,7 +10,7 @@ exclusively available to **Administrators** through the *System Administration*
 **Instructors** can access the build overview for a specific course through the *Build Overview* button located in *Course Management*.
 This view displays only the queued, running, and finished build jobs associated with the selected course.
 
-.. figure:: programming/buildQueueCourseManagement.png
+.. figure:: local-ci/buildQueueCourseManagement.png
    :alt: Build Overview Course Management
    :align: center
 
@@ -27,7 +27,7 @@ Jobs are dynamically added to and removed from the queue in real-time.
 Users have the ability to cancel any job in progress. The table provides the following information:
 
 
-.. figure:: programming/running-build-jobs.png
+.. figure:: local-ci/running-build-jobs.png
    :alt: Running Build Jobs
    :align: center
 
@@ -43,7 +43,7 @@ Users also have the option to cancel any job that is queued.
 The table below displays the following information:
 
 
-.. figure:: programming/queued-build-jobs.png
+.. figure:: local-ci/queued-build-jobs.png
    :alt: Queued Build Jobs
    :align: center
 
@@ -59,7 +59,7 @@ Instructors can also access build logs with detailed information about the build
 The table provides the following information:
 
 
-.. figure:: programming/finished-build-jobs.png
+.. figure:: local-ci/finished-build-jobs.png
    :alt: Finished Build Jobs
    :align: center
 

docs/user/icl/local-continuous-integration.rst

@@ -0,0 +1,27 @@
+.. _local-ci:
+
+Continuous Integration
+======================
+
+Continuous Integration (CI) is a software development practice where developers frequently merge their code changes into a shared repository. Each change is automatically built and tested, which helps to:
+
+- Detect and address integration issues early
+- Ensure code quality and consistency
+- Streamline the development process
+
+Artemis Local CI is our implementation of these CI principles, tailored to support the Artemis learning platform.
+It provides tools and views to help users build and test in programming exercises effectively.
+
+This document will introduce you to the key components of Artemis Local CI: the Build Agent View and the Build Overview View.
+These tools will assist you throughout your development workflow on the Artemis platform.
+
+Build Agent View
+^^^^^^^^^^^^^^^^
+
+.. include:: local-ci-build-agent-view.inc
+
+
+Build Overview View
+^^^^^^^^^^^^^^^^^^^
+
+.. include:: local-ci-build-queue-view.inc