tests_hw: GHA introduce Raspberry PI runner

[mgeeIOL]

Add additional tests utilizing the new Raspberry PI 5 Github actions agent.

Goal of this PR is to get to a similar point as with the current linux build tests. (with mini, demo, and systests)

[casaroli]

bear with us. we are going to add the arm64 container image in 2 weeks, so you can use that image in rpi.

for now, if you like you can just build the image manually and use it in the runner.

[casaroli]

I am not sure if it is worth to test (Zephyr) native_sim on arm64.

I would instead just run mini, demo, systests natively on rpi like we do in Linux.

[mgeeIOL]

I am not sure if it is worth to test (Zephyr) native_sim on arm64.

I would instead just run mini, demo, systests natively on rpi like we do in Linux.

Makes sense, I will remove the zephyr tests for now

[mgeeIOL]

bear with us. we are going to add the arm64 container image in 2 weeks, so you can use that image in rpi.

for now, if you like you can just build the image manually and use it in the runner.

bear with us. we are going to add the arm64 container image in 2 weeks, so you can use that image in rpi.

for now, if you like you can just build the image manually and use it in the runner.

I can wait on this if needed, for clarification are you referring to the devcontainer images or adding ARM64 to the ocre runtime support? My previous understanding was there was no intention to add ARM64 to the supported build targets.

I am running the current builds outside of a devcontainer to keep the entire process localized to arm to replicate individual runs, I plan on introducing the devcontainer later if that is your concern.

[kr-t]

I think based on earlier discussions, since the RPI Matt has is only 1GB version, running docker containers there might not be the best case.
But also maybe modifying the containerized workflow we have right now.

Would it maybe more sense to just create an additional workflow as part of our hardware tests and run it as a last step, similarly to how we run U585 tests right now?

This way we won't be needing to modify current containerized workflow, and Matt can customize the new one to run natively on the RPI, as he wanted.

What do you think @mgeeIOL @casaroli ?

[mgeeIOL]

There are pros and cons to separating the Raspberry Pi linux tests. The main reason I see to keep them together is to make it so changing linux tests only requires editing one file instead of two. If we need to add additional tests only on the raspberry pi in the future we can add additional workflows/files later in the overall workflow. Although I am not opposed to separating them now if we intend to run additional or modified tests on the raspberry pi.

I do not think running docker on the Raspberry Pi will be the biggest problem, from some brief testing the Raspberry Pi seemed to run Ubuntu containers fine.

I am not strongly opinionated either way, I had the files separate initially as that just seemed more logical given the linux tests do not necessarily require a container to run successfully but I am not opposed to using a container for ensured consistency between runs.

[kr-t]

We can maybe then try building arm based docker containers via GH runners (if they are available freely for open source projects like ocre) and then you'd just add RPI to the linux job, and pull the appropriate container, if it works as you claim.

[mgeeIOL]

I was able to fix the raspberry pi runner issues and get tests to pass. I had to run the linux tests separately outside of a container as the dev containers currently do not include an ARM container.

The tests used are a copy of relevant linux tests, let me know if you want to add more tests to run on the raspberry pi.

[kr-t]

Hi Matt, on latest main we have added container for arm64: https://github.com/project-ocre/ocre-runtime/pkgs/container/ocre-runtime%2Fdevcontainer-linux

Maybe you want to check, whether using the rpi w the container could be a better idea. this way you'd just need to add a matrix for linux, add your runner and that shall automatically pull the correct container. Ideally in this case you'd need to maybe add to matrix additional arguments, for example running as a user for easier cleanup (same as we had before we started using gh images)

[mgeeIOL]

Updated to use the Arm container and the linux.yml file, let me know if anything else is needed

[kr-t]

I don't think we want this. The linux devices are stable, and I don't think we need additional safeguards as we have with the U5 tests. I suggest we remove this concurrency part.

[kr-t]

Otherwise this looks good and I think we can merge it after.

[mgeeIOL]

Removed this section, let me know if anything else is needed