Programming exercises: Simplify parsing of test suites in Jenkins setups

[b-fein]

Checklist

General

• I tested all changes and their related features with all corresponding user types on a test server.
• This is a small issue that I tested locally and was confirmed by another developer on a test server.
• Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
• I chose a title conforming to the naming conventions for pull requests.

Server

• Important: I implemented the changes with a very good performance and prevented too many (unnecessary) and too complex database calls.
• I strictly followed the server coding and design guidelines.

Changes affecting Programming Exercises

• I tested all changes and their related features with all corresponding user types on a test server configured with Gitlab and Jenkins.

Motivation and Context

JUnit-XMLs can either have a top-level <testsuite> or a <testsuites> element. The Jenkins plugin so far only handled the <testsuite> case since this was used for most exercises. For the other format a workaround using text replacement in the XML was used.

With #9490 and #9691 LocalCI setups can parse such top-level <testsuites> elements. The Jenkins plugin as of version 1.10.0 can do it, too.

Description

Removes the workaround from the Jenkins pipeline templates since they are no longer needed.

Steps for Testing

Prerequisites:

• 1 Artemis instance connected to Jenkins (e.g. legacy artemis-test2 deployable via Bamboo)
• 1 Instructor

1. Create a new exercise using a programming language that makes use of the <testsuites> in the XML. E.g. Haskell, Rust, Javascript, Typescript, Rust.
2. All test cases for the solution submission should pass.

Testserver States

Note

These badges show the state of the test servers.
Green = Currently available, Red = Currently locked
Click on the badges to get to the test servers.

Review Progress

Code Review

• Code Review 1
• Code Review 2

Manual Tests

• Test 1
• Test 2

Test Coverage

unchanged

Screenshots

n/a

---

@coderabbitai ignore

[magaupp]

I think we need to reference the explicit plugin version in docker/jenkins/plugins.yml because this depends on the new feature:

# Third-party plugins required by Artemis.
plugins:
  ...
  - artifactId: test-notifications
    source:
        url: https://github.com/ls1intum/jenkins-server-notification-plugin/releases/latest/download/test-notifications.hpi

Keeping latest wouldn't cause a rebuild of existing docker deployments, which would keep using the previously cached version.

[b-fein]

@magaupp As far as I understand the documentation regarding the plugins, this is mostly used to provide some plugins automatically during the initial setup but then you are expected to update the plugins from the UI as usual. Updating the version here would not override the currently installed version of already running setups.

When jenkins container starts, it will check JENKINS_HOME has this reference content, and copy them there if required. It will not override such files, so if you upgraded some plugins from UI they won't be reverted on next start.

https://github.com/jenkinsci/docker/?tab=readme-ov-file#usage-1

Therefore, providing an exact version here does not really make sense, I think. It’s easier to keep the latest version here so that new users will always get the currently latest version without us having to maintain and remember to update it.

[dfuchss]

/cc @SoftHeinrich can you test this PR on our test systems?

[SoftHeinrich]

tested

[dfuchss]

@SoftHeinrich tested it on our systems

[chrisknedl]

Tested with a Rust exercise on my local Jenkins setup. All testcases pass in the solution repo. 👍

[magaupp]

@b-fein The documentation refers to plugins installed to the image and plugins installed to the container (JENKINS_HOME).
https://github.com/jenkinsci/docker/?tab=readme-ov-file#upgrading-plugins:

By default, plugins will be upgraded if they haven't been upgraded manually and if the version from the docker image is newer than the version in the container. Versions installed by the docker image are tracked through a marker file.

The jenkins-plugin-cli RUN step of the Dockerfile would install the hpi file referred in the plugins.yml to the image. But because no files changed, this step would not be repeated on a rebuild of the image. Then the cached build layers with the old version would be used for the image. Updating the version in the plugins.yml would cause a cache bust and rerun the build step.

I noticed that Artemis' upgrade documentation instructs a no-cache build for the manual build but a normal build for the compose build:
docker build --no-cache -t jenkins-artemis
docker compose -f docker/<Jenkins setup to be launched>.yml up --build -d
So a manual build would succeed without issues but the compose one not.

I'm interested in the specifics of the tester's deployments. Maybe it's not an issue in actual deployments.

[b-fein]

So a manual build would succeed without issues but the compose one not.

Then I’ll update the docker compose command in a separate small PR. That should be the easiest fix that will not incur future additional maintenance. It also ensures the other plugins are updated.

$\Rightarrow$ #9816

[magaupp]

Code