Enable CI via GitHub Actions

[jserv]

Currently, the Linmo operating system offers multiple applications for API validation, but these require manual execution. A more effective approach would be to download the GNU Toolchain for RISC-V, compile Linmo from source, execute automated tests through QEMU, and verify results against established criteria. This entire process can be streamlined by integrating it into a CI pipeline using GitHub Actions.

[Damien-Chen]

Hi @jserv, Can I take this issue ?

[G36maid]

Hi @jserv,

I'm interested in this issue and have created a basic POC with build-only testing:
https://github.com/G36maid/linmo/actions/runs/15950977836
Regarding “verify results against established criteria” — currently, some apps are self-testing, while others require manual output inspection.
Before proceeding, I'd like to clarify what kind of test automation or verification is expected.

[jserv]

I'm interested in this issue and have created a basic POC with build-only testing: https://github.com/G36maid/linmo/actions/runs/15950977836 Regarding “verify results against established criteria” — currently, some apps are self-testing, while others require manual output inspection. Before proceeding, I'd like to clarify what kind of test automation or verification is expected.

This looks excellent. The plan is to build Linmo using both GNU and LLVM toolchains, then run validation applications like cpubench to verify the results. Finally, we should generate a comprehensive report similar to the one shown here:
sysprog21/threadx#2

[jserv]

Hi @jserv, Can I take this issue ?

Help review pull request #12 as a collaborative effort.

[jserv]

Step 1: Build Linmo Kernel

Objective: Ensure the Linmo kernel builds cleanly with both supported toolchains.

• Toolchains:
  • GNU Toolchain for RISC-V (e.g., riscv-none-elf-gcc)
  • LLVM Toolchain with clang + lld
• Tasks:
  • Build the kernel (without applications) using GNU.
  • Build the kernel again using LLVM.
  • Both builds must succeed without warnings treated as errors (e.g., -Werror).

Step 2: Application Crash Sanity Check

• Objective: Confirm that every application does not trigger an exception within 5 seconds under QEMU.
• Tasks:
  • Iterate over all applications under app/, excluding known test cases.
  • For each application:
    • Build using GNU (or LLVM).
    • Run under QEMU with timeout set to 5 seconds.
    • Detect and validate exception trap (e.g., trap handler invoked).
• Validation Criteria:
  • Execution must not terminate with an exception (non-zero exit, or kernel trap message seen in output).

Step 3: Run Dedicated Functional Tests

• Objective: Validate correctness of core subsystems using specialized test applications.
• Example Case: app/mutex.c
• Tasks:
  • Build and run under QEMU with a timeout (e.g., 5 seconds).
  • Capture standard output.
  • Check for all of the following lines in output:

    Fairness: PASS
    Mutual Exclusion: PASS
    Data Consistency: PASS
    Overall: PASS
    

• Validation Criteria:
  • All 4 PASS strings must appear in the output.
  • If any is missing, mark the test as failed.

[Damien-Chen]

@jserv , should we integrate static code analysis like CodeQL into Github Actions ?

[jserv]

should we integrate static code analysis like CodeQL into Github Actions ?

Sure! The static analysis can be added after the above 3 steps.