workflow tests for zephyr 4.3 and 4.1#10314
Open
night1rider wants to merge 1 commit intowolfSSL:masterfrom
Open
workflow tests for zephyr 4.3 and 4.1#10314night1rider wants to merge 1 commit intowolfSSL:masterfrom
night1rider wants to merge 1 commit intowolfSSL:masterfrom
Conversation
wolfSSL-Fenrir-bot
left a comment
There was a problem hiding this comment.
Fenrir Automated Review — PR #10314
No scan targets match the changed files in this PR. Review skipped.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds GitHub Actions coverage for wolfSSL on Zephyr v4.1.0 and v4.3.0 across the
native_simandfrdm_rw612/rw612boards. The existing.github/workflows/zephyr.ymlonly exercises Zephyr 2.7 / 3.4 / 3.5; this new workflow extends CI to the 4.x line so regressions on current Zephyr releases are caught.Files added
.github/workflows/zephyr-4.x.yml— workflow definition..github/scripts/zephyr-4.x/zephyr-test.sh— Docker-driven build/run driver. Uses the officialghcr.io/zephyrproject-rtos/zephyr-buildimages so the right Zephyr SDK is selected per release..github/scripts/zephyr-4.x/external_libc.conf— Kconfig overlay forcingCONFIG_EXTERNAL_LIBC=y(mirrors a customer build configuration).Coverage — 18 parallel matrix jobs
external_libc.confoverlaynative_simnative_simfrdm_rw612/rw612frdm_rw612/rw6122 versions × 2 boards × 3 samples × 2 conf variantsminus the 6frdm_rw612 + extlibccells (theexternal_libc.confoverlay is anative_sim-only configuration).How it runs
pushtomaster/main/release/**and on every PR — same pattern as the existing.github/workflows/zephyr.yml.github.repository_owner == 'wolfssl', so it only runs on the upstream repo and PRs targeting it.github.event.pull_request.head.repo.clone_url/head.ref); for push events it tests the current repo and ref.zephyr-test.shinside the officialghcr.io/zephyrproject-rtos/zephyr-buildimage. The script auto-selects the SDK image per Zephyr version:v0.27.4(SDK 0.17.0)v0.28.7(SDK 0.17.x)native_sim) the script runs the resulting binary and waits for a success string (Benchmark complete,Test complete, orClient Return: 0) with a 5-minute timeout.frdm_rw612/rw612it stops at "Build succeeded" — no emulator run..github/scripts/zephyr-4.x/logs/is uploaded as an artifact (5-day retention).Verifying a run is testing the PR's actual code
Each job log makes it easy to confirm the workflow built and ran the PR's wolfSSL source rather than master. Look for these four signals (lines reproduced from the smoke-test run on
night1rider/wolfssl @ zephyr-4.x-workflows):Resolved repo and branch echoed at the top of the log:
These come from
github.event.pull_request.head.repo.clone_urlandhead.ref.Injected
west.ymlpoints at the PR fork:west updateactually fetched from that fork at the PR head commit:The short SHA (
3507aefhere) should match the PR's latest commit on GitHub.The sample binary the workflow ran was built from the fetched source (visible in the build phase as object files under
modules/crypto/wolfssl/...and a successful run, e.g.Benchmark complete).Caveat: the script fetches the PR branch tip with
--depth=1rather than GitHub's computed merge commit, so the build is "PR branch as-is" rather than "PR branch merged into base". This matches existing Jenkins-style PR validation behavior; if strict "merged into master" semantics are ever needed, that would be a separate follow-up.