search

golioth / golioth-zephyr-sdk

Golioth SDK For Zephyr
https://www.golioth.io
Apache License 2.0
65 stars 20 forks source link

bump Zephyr to 3.5.0-rc3 and NCS to tip of main (2.5.0-rc1+) #438

Closed mniestroj closed 8 months ago

mniestroj commented 8 months ago

Bump Zephyr to latest release candidate to test it before final 3.5.0 release.

Bump NCS to tip of main (slightly newer than 2.5.0-rc1 tag), to find potential nRF91* platform regressions.

Replace rand32.h with random.h to suppress header deprecation warning. Add a workaround for older Zephyr versions (like the one used by NCS fork) by providing random.h just for internal Golioth SDK library visibility.

Tested on:

github-actions[bot] commented 8 months ago

Visit the preview URL for this PR (updated for commit b41f04d):

https://golioth-zephyr-sdk-doxygen-dev--pr438-bump-zephyr-rw7hli19.web.app

(expires Thu, 26 Oct 2023 13:48:42 GMT)

🔥 via Firebase Hosting GitHub Action 🌎

Sign: a389eefadf4b4b68a539327b3459dd66c142cf49

mniestroj commented 8 months ago

Looks like the build test failed, because the runner ran out of disk space. I hit the same error in the CP SDK, and you should be able to fix it by parallelizing the build similar to golioth/golioth-firmware-sdk@5eb86b7

Proposed solution (https://github.com/golioth/golioth-zephyr-sdk/pull/439) is slightly different, much smaller in boilerplate code size, but seems like a perfect fit for what we have now. This will give some input for comparison with the solution you proposed and implemented for CP SDK. Both are fine, maybe they can be combined together. My implementation was inspired by Zephyr CI matrix (but they use arbitrary number of matrix instances, which is then passed to twister, which decides by its own how to divide all test cases to be executed).

mniestroj commented 8 months ago

@sam-golioth Do you have some idea about why build job is "Expected - Waiting for status to be reported"? It looks like a job that is the parent for 3 matrix jobs. Those 3 jobs are successful, but still, build is somehow pending. In case that is something new, I'll just investigate what the issue might be (I guess something in workflow specification which is not exactly what GitHub expects, or I just need close/reopen to workaround some corner case in GitHub CI).

sam-golioth commented 8 months ago

@sam-golioth Do you have some idea about why build job is "Expected - Waiting for status to be reported"?

I had marked the build job as a required check after it failed on this PR earlier. The reason is because when a runner runs out of disk space, the job is marked as "skipped" not "failed" and the PR UI treats skipped jobs like successful jobs (it still said "All checks have passed"), so it wasn't obvious that there was an issue. Marking it as required makes sure we don't miss when a job is "skipped". It looks like there isn't a way to mark the parent job as required, so I've just removed the requirement. We can mark the child jobs as required later, after this gets merged.

Also, the job being marked as "skipped" and not "failed" might be due to something in our workflow rather than an unsolvable GitHub actions issue, but I didn't want to put in the time to investigate that right now. Just something to keep in mind for the future.