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.