Initialize CI for PullRequest Testing

[MatthiasBSchaefer]

This PR adds the yml file to .github/workflows in order to start the CI for testing PullRequests with the ltx-resim tool.
infrastructure to run the CI-tests is currently hosted and maintained by LTX

see PRs #4725 #4763 #4764 #4765 , which are tests of the CI on a separate branch

[beutlich]

The log is pretty verbose and it's not obvious what might be the reason for failure at first sight.

I have saome ideas:

1. Can we reduce the log verbosity. Can we have a configurable log verbosity.
2. Can we add problem matchers? See for example https://github.com/modelica/ModelicaStandardLibrary/blob/master/.github/moparser.json or https://oneuptime.com/blog/post/2026-01-30-github-actions-problem-matchers/view.
3. Can we upload the comparison reports using actions/upload-artifact?

[beutlich]

Suggested change

	name: PR_testing
	on:
	# Triggers the workflow on push or pull request events but only for the "main" branch
	pull_request:
	# Allows you to run this workflow manually from the Actions tab
	workflow_dispatch:
	# A workflow run is made up of one or more jobs that can run sequentially or in parallel
	name: CI ReSim
	on:
	pull_request:
	workflow_dispatch:

[beutlich]

Suggested change

	runs-on: self-hosted
	runs-on: [ self-hosted, linux, regression-testing ]

[beutlich]

Suggested change

	- name: checkout_pr_repo
	- name: Checkout code

[beutlich]

Suggested change

	runs-on: self-hosted
	runs-on: [ self-hosted, linux, regression-testing ]

[beutlich]

Suggested change

	name: link_modelica
	name: Build libraries

Not sure, what is meant by "link".

[beutlich]

Suggested change

	- name: run modelica
	- name: Run tests

[beutlich]

Suggested change

	name: link_modelicatest
	name: Build libraries

[MatthiasBSchaefer]

The enviroment is meant to create\show the links to the reports.
So "Report modelicatest" might be a good name

[beutlich]

Suggested change

	- name: run modelicatest
	- name: Run tests

[beutlich]

Do not use hard-coded URIs for https://serv.ltx.de (here and in other places), instead prefer variables via https://github.com/modelica/ModelicaStandardLibrary/settings/variables/actions. This way LTX can move its server while workflow keeps untouched.

[beutlich]

For the sake of transparancy, can we add all the CI bash scripts to a new folder ReSim in .CI? Otherwise it will be pure magic for library officers. Usually and as best practice the CI scripts are maintained along with the repo under test.

[MatthiasBSchaefer]

@beutlich
Thank you for your detailed review !

1.) I know, log is pretty verbose. But it is not really meant to be analyzed. Finding errors (like example Modelica.Blocks.Examples.xxx is not running anymore due to the changes in the PR) can be done in the published reports. The log is more or less to analyze possible errors in the workflow itself by us (LTX). We can reduce the logging once we are sure the workflow is stable. (without any changes inside this repository)

2.) probably we could introduce problem matchers, but may not be necessary due to 1.)

3.) We discussed this in the MAP-LIB meetings. Upload artifacts would induce the need to download the reports (which are not that small) , unzip and then open in a browser. These steps, we want to avoid, making the reports directly clickable by publishing on our server.

4.) Thank you for the very good hint with the variables instead of hard links!

5.)We can publish the main shell scripts called by the CI. But these are mainly running the Modelica tools inside docker containers. And we wont publish our regression testing tool itself, nor the docker files, due to intellectual property. So publishing the scripts is only partially helpful concerning transparency, but would induce a change of these scripts (and such a change in the MSL) in order to add a further Modelica tool (e.g. Simulation X) to the regression testing.

6.) Your proposed naming of the jobs is fine for me.