Run the DML tests from GitHub Action intead of TeamCity build

[andreashedstrom-intel]

No description provided.

[mandolaerik]

Some paths are hard-coded to our env. Would it make sense to start with some of the paths overrideable, like

if [ -n "$(DMLC_CC)" ] ; then export DMLC_CC=/usr/itm/... ; fi

... and probably similar for PACKAGE_REPO?
We can do the same later on request, of course.

[andreashedstrom-intel]

Yes, this is just a quick hack to get the box moved from TC into GH ; we`re still running (or I was assuming we would still be running) on our local runners where we have simicsmp adn /usr/itm/gcc .

If we want to run outside on generic runners, we must somehow package up a docker image (or an image diff that you apply to some standard ubuntu image) that provides a decent GCC and Simics Base. I don't know how to do that, so that will have to be done and resolved later.

[andreashedstrom-intel]

In order for this to work we need to assign some self-hosted runners ; and I don't know how or to what extent we can do that in the (somehwat?) public DML repo. There must be some rules and restrictions here I guess.

If you look here, there seems to be one internal intel runner availalbe; but it obviously don't know simicsmp so we need to solve that the. https://github.com/intel/device-modeling-language/actions/runners?tab=self-hosted

The way I see it we have two options:

1. Add a few of our self-hosted IGK lab lgrNN runners to the DML repo. We can block the workflow to only run when the run-tests label is set (or whatever label you want to use). The Base setup already plays with labels so we know how to do that.
2. Alternatively we could figure out how to produce docker images with ubuntu + simics ; I have no idea what kind of rules apply here or even how to do that. We need to talk with someone how knows this webtech

[andreashedstrom-intel]

and there's a 3rd option:
3) We run DML from ci-tools repo. The ci-tools repo is internal and already runs on our local self-hosted runners. So the flow, with hard-coded ITM paths, will just work out-of-the-box. If we create a workflow_dispatch triggered workflow, then you as a user on the inside can trigger it using the gh workflow run XXX syntax, similar to what you now do (invoking the verify-dml-pr.sh script from ci-tools).