CI: Do Zephyr build tests on known good and latest versions

[wmamills]

Allow Zephyr testing to either use locked known good values or the very latest versions.

The known good versions are best for PR checking as if the build fails it is almost always the PR itself that broke it.

The latest version is good for periodically checking compatibility with the very latest Zephyr changes.

For now we run both on pushes and PRs.

We also run main against the latest zephyr check weekly as a look ahead.

Fixes: #295

[wmamills]

@arnopo
This branch does not contain the v3.7.0 fix so the "latest" builds will always fail.
To show the logic I have hard coded Zephyr v3.6.0 and SDK 0.16.5-1 so they will be noticeably different than latest.
We should merge the fix for v3.7.0 before this one and I will rebase and then set known good values of v3.7.0 and 0.16.8

[wmamills]

@arnopo @tnmysh @edmooring
rebased to main.
Now that main is compatible with Zephyr v3.7.0, use that as the known good version.
Also use 0.16.8 as the known good SDK version (which will also be the latest for now)
The All checks have passed section is what we should see in a PR.
If a PR fails against Zephr known good it should not be merged.
If a PR fails the Heath Check Zephyr latest, that is probably not something the PR did. You can check via the latest main heath check or running a new one manually via the web interface.

[arnopo]

what about stable instead of "good" ?

[tnmysh]

Ack.

[wmamills]

I really don't like stable. The know good version does not need to be a release, just a recent point that is know to work. If it is a release, it does not need to be the most recent stable release.

However "know good version" is a term I have used for decades and I am not the only one:
https://github.com/GoogleChromeLabs/chrome-for-testing?tab=readme-ov-file#json-api-endpoints

I can add _version. That makes it easier to understand.

[arnopo]

question: what happen if it fails. A message is sent on the mailing list, or do we have to check action result each week?

[wmamills]

Pushed with some language updates as describe above.

[wmamills]

@arnopo why do we ignore changes to cmake/* and scripts/*?? Changes there are the most likely to cause problems for the builds.

Are you OK if I start another PR to remove those ignore paths?

[wmamills]

question: what happen if it fails. A message is sent on the mailing list, or do we have to check action result each week?

The answer seem to be here:
https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/monitoring-workflows/notifications-for-workflow-runs

I don't see anyway to send that to an email list. We can change who it goes to by disable and then enable. The last enable is the winner.

We could also add a badge on the readme.

[arnopo]

@arnopo why do we ignore changes to cmake/* and scripts/*?? Changes there are the most likely to cause problems for the builds.

Mainly to avoid issue with checkpatch and to avoid running build on non-library code (no true for cmake)

Are you OK if I start another PR to remove those ignore paths?

yes sure!

[arnopo]

question: what happen if it fails. A message is sent on the mailing list, or do we have to check action result each week?

The answer seem to be here: https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/monitoring-workflows/notifications-for-workflow-runs

I don't see anyway to send that to an email list. We can change who it goes to by disable and then enable. The last enable is the winner.

We could also add a badge on the readme.

Regarding the article you pointed out and this article: https://docs.github.com/en/rest/checks/runs?apiVersion=2022-11-28,
we should be able to return another status such as neutral , or action_required

In such case we could run it for each PR but returning something else than failure with an explicit print in action log:
" If the error reported is not related to your PR, you can ignore it, it probably related to an internal Zephyr error"