CI Improvements: Add RTAI build

[hdiethelm]

In this PR, I will try to improve the CI

There will be a few pushes, including some that should fail on purpose to test if everything works as desired. Just tell me if I abuse the CI to much and I will find a different solution.

Edit: I think it makes sense to merge this and continue in a separate PR so RTAI is not broken again in a few weeks.

[hdiethelm]

@BsAtHome I already started as discussed in #3978 and it seams to do something.

Seams my first try already fails as it should: https://github.com/hdiethelm/linuxcnc-fork/actions/runs/25117897747/job/73610085493

Next try is with your fix cherry-picked, so I can test if it passes now.

[hdiethelm]

@BsAtHome
This stage passes now: https://github.com/hdiethelm/linuxcnc-fork/actions/runs/25118553864/job/73612475396
I think it would make sense to merge this as soon as #3981 is merged, so RTAI doesn't fail anymore. The CI can still be improved some more afterwards.

[hdiethelm]

@NTULINUX
Does it make sense to take these packages from https://www.linuxcnc.org/dists/trixie/base/binary-amd64/ to test RTAI build or should I use something else?

rtai-modules-5.4.279_5.3.3-linuxcnc_amd64.deb 
linux-image-5.4.279-rtai-amd64_5.4.279-rtai-amd64-1_amd64.deb 
linux-headers-5.4.279-rtai-amd64_5.4.279-rtai-amd64-1_amd64.deb

[BsAtHome]

This is an improvement!

Besides running into some performance issues that are of github's own making... They often stall on getting packages. You mentioned a more mature installed docker image. Do you know how that works?

[BsAtHome]

...
Get:9 http://linuxcnc.org/ trixie InRelease [31.7 kB]
Err:9 http://linuxcnc.org/ trixie InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E43B5A8E78CC2927
Reading package lists...
W: GPG error: http://linuxcnc.org/ trixie InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E43B5A8E78CC2927
E: The repository 'http://linuxcnc.org/ trixie InRelease' is not signed.

[BsAtHome]

BTW, I killed the CI run after I saw the failure (only because I am at the computer...). No need to run the other stuff while there are errors. It will only delay the new test and unnecessary use resources.

[hdiethelm]

This is an improvement!

Besides running into some performance issues that are of github's own making... They often stall on getting packages. You mentioned a more mature installed docker image. Do you know how that works?

Let's put it that way: I know how to do it in Gitlab. And it is sure possible in Github. What you do basically:

1. Build docker images that contains all the needed packages
2. Push these docker image to the github
3. Use it all over in the CI

The only issue I see is that when a new dependency is added, the image has to be updated somehow. But a hybrid approach could be used:

• Install all dependency's from a certain state
• The runner installs new dependenc's
• From time to time, you update the images

The images can be generated directly from the linuxcnc repo or also from an other repo. Normally, you have something like a linuxcnc-build-image repo which does this, so you can push tags there to trigger a build.

[hdiethelm]

BTW, I killed the CI run after I saw the failure (only because I am at the computer...). No need to run the other stuff while there are errors. It will only delay the new test and unnecessary use resources.

I forgot one line, I have to try again. This CI stuff is always annoying, commit&push until it works. Just tell me if it gets to much and I can try to create my own runners.

[hdiethelm]

Now it works again. This does the job already for RTAI.

For future improvements, I would need to know a few details about how the LinuxCNC github is set up.

• Are the runner from github or on someones private machine?
• Is there enough space to can push a few GB of docker or runner images? This will generate costs.

If you don't feel like sharing this here, you contact me by mail. If you don't feel like sharing this at all, I can create a setup that works in my gitlab and share it. Internals are often a bit sensitive because they can be exploited sometimes.

Or I can also give you hints how to do it and review your changes.

What I found so far:
https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry
https://docs.github.com/en/actions/how-tos/manage-runners/larger-runners/use-custom-images
Similar than in gitlab, just a different flavor.

[hdiethelm]

After #3981 got merged, I re-based on top of master and squashed the test commits.

I will mark this as ready, feel free to merge so RTAI is not broken again after the next merge. As already stated, I am ready to help improving the CI even more.

[BsAtHome]

@andypugh, do you know what the deal is with github and CI usage and storage limits? There are some open questions from #3983 (comment) and you probably know more about potential (historic) deals than anybody else.

Anyhooo, this PR should be merged, I think, because it addresses the long standing issue of continual RTAI breakage.

[NTULINUX]

@NTULINUX Does it make sense to take these packages from https://www.linuxcnc.org/dists/trixie/base/binary-amd64/ to test RTAI build or should I use something else?

rtai-modules-5.4.279_5.3.3-linuxcnc_amd64.deb 
linux-image-5.4.279-rtai-amd64_5.4.279-rtai-amd64-1_amd64.deb 
linux-headers-5.4.279-rtai-amd64_5.4.279-rtai-amd64-1_amd64.deb

I've made a lot of improvements since then, I would recommend using 5.4.302 from here:

https://github.com/NTULINUX/RTAI/releases/tag/v5.3.4

[hdiethelm]

I've made a lot of improvements since then, I would recommend using 5.4.302 from here:

https://github.com/NTULINUX/RTAI/releases/tag/v5.3.4

I switched to these packages and left the old variant commented out if someone needs it one day.

[NTULINUX]

Awesome, thanks!