fix(ci): run artillery from node_modules instead of the broken action

[Mtze]

What and why

Follow-up to #38. The Artillery job has two independent breakages; #38 fixed one, this fixes the other.

1. Fixed in chore(renovate): onboard to shared Renovate preset #38 (already on main): npx playwright install --with-deps runs apt-get update, and packages.microsoft.com now returns 403 for the azure-cli and prod repos, aborting apt with exit 100 before any browser downloads.
2. This PR: with apt working, the job reaches the next step and dies at /entrypoint.sh: 20: /home/node/artillery/bin/run: not found. The container image behind artilleryio/action-cli@v1 no longer has a working entrypoint.

artillery ^2.0.24 is already a devDependency and npm ci has run by that point in the job, so npx artillery run does exactly the same work without the container in the way.

Neither failure is a test failure. The job has been red since its last green run on 2026-05-22.

How it was verified

• actionlint clean on the modified workflow.
• The two failure modes were read out of the actual job logs on runs 33086633045 (apt, exit 100) and 33087181179 (missing entrypoint), so this is not guesswork about what is wrong.
• Not verified: that the load test itself passes. It runs against the live deployment at https://theia.artemis.cit.tum.de and needs KEYCLOAK_USER/KEYCLOAK_PWD, so it cannot run locally. This PR gets the job to the point where the scenario actually executes; whether the scenario then passes is the first real signal anyone has had from it since May.

Deployment impact

• None of the above

Risk and rollback

CI-only, single step, revert to roll back.

Worth a separate conversation: this is a load test against production wired to pull_request. Every PR in this repo drives traffic at the live TUM deployment, and it needs secrets that a fork PR would not have. Restoring it to working order is the right fix for a broken job, but whether it belongs on pull_request at all - rather than on a schedule or workflow_dispatch - is a design question I have not touched here.

[coderabbitai]

Warning

Review limit reached

Next included review available in 39 minutes.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 821d484f-5ae3-459e-a845-63a0cbb77d92

📥 Commits

Reviewing files that changed from the base of the PR and between 029fba7 and 45f23a8.

📒 Files selected for processing (1)

• .github/workflows/artillery-tests.yml

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Mtze]

Update after watching this run: the job is now green, but it is a vacuous green. Worth being explicit, because "artillery = SUCCESS" on this PR is misleading on its own.

The step output:

Test run id: tfd7k_jz98m4pgzy3mrh3arc76dqpehzkz5_pq6p
Unknown phase spec definition, skipping.
{"duration":1,"arrivalRate":null}
This should not happen
--------------------------------
Summary report @ 15:34:51(+0000)
--------------------------------

No measurements recorded during this period

So artillery starts, discards its only phase, measures nothing, and exits 0.

Root cause. tests/ide/scalable/artillery/Artillery.ts builds its phase from an env var:

const numUsers = parseInt(process.env.NUM_INSTANCES!, 10);
...
phases: [{ duration: 1, arrivalRate: numUsers }],

NUM_INSTANCES is not in this workflow's env: block — it only sets KEYCLOAK_USER, KEYCLOAK_PWD and LANDINGPAGE_URL. So parseInt(undefined, 10) is NaN, which serialises to null, and artillery rejects the phase spec and skips it. The non-null assertion (!) makes TypeScript accept it at compile time, so nothing catches this before runtime.

There is a second problem waiting behind it: the config sets headless: false, which will not work on a hosted runner without a display once the phase actually runs.

What this PR does and does not do. It fixes what it claims: the step no longer dies at /home/node/artillery/bin/run: not found, and artillery genuinely executes. It does not make the load test measure anything — that needs NUM_INSTANCES set and headless: true (or xvfb).

I have deliberately not fixed that here, because doing so turns this into a real load test firing at the live TUM deployment on every single pull request, which is a decision rather than a bug fix. The prior question is whether this belongs on pull_request at all rather than on a schedule or workflow_dispatch.

Happy to do either — say which.