Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions .github/workflows/linux.yml
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,8 @@ on:
type: string

jobs:
build-linux:
name: Linux build
build-and-run-linux:
name: Build and Run
runs-on: ["self-hosted", "build-server"]
container:
image: ghcr.io/${{ github.repository }}/devcontainer-linux:${{ inputs.devcontainer-tag }}
Expand Down
32 changes: 28 additions & 4 deletions .github/workflows/zephyr.yml
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ on:

jobs:
build-zephyr:
name: Zephyr build
name: Build
runs-on: ["self-hosted", "build-server"]
container:
image: ghcr.io/${{ github.repository }}/devcontainer-zephyr:${{ inputs.devcontainer-tag }}
Expand Down Expand Up @@ -76,12 +76,36 @@ jobs:
build/zephyr/zephyr.dts
build/zephyr/.config

- name: Test native_sim mini
if: startsWith(matrix.board, 'native_sim/') && matrix.app == 'mini'
run-zephyr:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we shall discuss how we want to design this. We are back to sequential vs matrix run;
additionally, this workflow only works with native_sim and native_sim/64 targets, since we actually run the app. For the real-hardware devices other means will be necessary. Nevertheless, the high-level naming seems to be clear in this case.

Image

Matrix builds give us more versability, but take longer in cases like this.

@casaroli wdyt?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P.S. Moreover, matrix is setup to accept new samples/boards, but the expected output is hardcoded; earlier we had that also as an input. If we are to go with matrices, we need to refactor them to be scalable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is ok. We will need to test different Zephyr builds, and this is the matrix for testing the native_sim (we can add the matrix later)

name: Run
needs: build-zephyr
runs-on: ["self-hosted", "build-server"]
container:
image: ghcr.io/${{ github.repository }}/devcontainer-zephyr:${{ inputs.devcontainer-tag }}
options: --user 1000:1000
strategy:
matrix:
board:
- native_sim/native/64
app:
- mini
steps:
- name: Set sane board name
run: |
BOARD=${{ matrix.board }}
echo "BOARD_NAME=$(printf "%s\n" "$BOARD" | tr / _)" >> $GITHUB_ENV

- name: Download build artifacts
uses: actions/download-artifact@v4
with:
name: ocre-zephyr-${{ env.BOARD_NAME }}-${{ matrix.app }}

- name: Run ${{ matrix.app }} on ${{ matrix.board }}
run: |
EXPECTED_LOG="powered by Ocre"
echo "Running application..."
stdbuf -oL -eL timeout 20s ./build/zephyr/zephyr.exe | tee zephyr_run.log
chmod +x zephyr.exe
stdbuf -oL -eL timeout 20s ./zephyr.exe | tee zephyr_run.log
echo "===== Checking for expected log ====="
if grep -q "$EXPECTED_LOG" zephyr_run.log; then
echo "[OK] Found expected log: $EXPECTED_LOG"
Expand Down