Add automated Kernel CI workflow

[shreeya-patel98]

Add automated kernel CI workflow with kselftest and PR creation
Implements a 5-stage GitHub Actions pipeline for automated kernel testing and PR creation.
Uses kernel-container-build automated-testing-v1 branch for build/test tooling.

Stage 1: Build (15-30 min)

• Checkout kernel source + kernel-container-build repo (automated-testing-v1)
• Build kernel in CIQ builder container with kABI checking
• Convert built container to QCOW2 VM image
• Upload: kernel-build.log, QCOW2 image

Stage 2: Boot Verification (2-5 min)

• Download QCOW2 image
• Boot kernel in QEMU (KVM or TCG) and validate login prompt appears
• Upload: boot logs

Stage 3: Kernel Selftests (20-40 min)

• Download QCOW2 image
• Execute comprehensive kselftests in QEMU with dual serial consoles
• Upload: kselftest TAP logs, dmesg output

Stage 4: Compare Results (1-2 min)
Purpose: Detect test regressions by comparing against base branch

Steps:

1. Checkout with full history (fetch-depth: 0) for git merge-base ops
2. Download current kselftest logs
3. Smart base branch detection:
   • For PRs: Uses PR's target branch
   • For pushes: Sorts branches by commit date, checks 30 most recent, finds closest common ancestor via git merge-base
   • Outputs: base_branch (reused by PR stage)
4. Download baseline logs from base branch (searches last 5 successful runs)
5. Compare results:
   • Counts passing/failing tests (before/after)
   • Fails if >±3 tests changed
   • Outputs: comparison_status, comparison_message

Stage 5: Create Pull Request (1-2 min)
Purpose: Auto-create/update PR after all tests pass

Prerequisites: Only runs if build + boot + kselftest passed, no regressions detected

Steps:

1. Check all stages passed and comparison_status != failed
2. Checkout (shallow: fetch-depth: 50) for commit messages
3. Download all artifacts (build/boot/test logs)
4. Extract statistics (pass/fail counts, build times)
5. Get commit info:
   • Single commit: Use commit message
   • Multiple commits: Create summary
6. Create/Update PR:
   • Reuses base_branch from compare-results (no duplication!)
   • Generate PR body with test results via create-pr-body.sh
   • Creates new PR or updates existing one

Signed-off-by: Shreeya Patel spatel@ciq.com

[bmastbergen]

Not a github action guru so maybe this is a dumb question:

I see that this has multiple jobs which means we end up checking out kernel-src-tree, checking out kernel-container-build, and installing host dependencies multiple times. I THINK these jobs end up running sequentially, so is there any reason not to have a single job with all of the same steps in it? I think this might also save a job from having to download the qcow2 artifact that was just uploaded by the previous job. Just wondering if a single job might shave off some time. Or maybe there is an upside to multiple jobs I don't know?

Overall I think this is looking great.

[shreeya-patel98]

@bmastbergen that's a great question, I also had this thought when I saw that some of the initial steps were getting repeated. The idea behind creating different stages was to identify the failures easily. It doesn't look very useful at this stage but when we will have multiple platforms, or even more stages, it becomes difficult to identify which stage failed. We will always have to keep checking the logs to identify the point of failure. But I do agree there is some duplicated code in the current setup which can be avoided. This is my first github action so I might also need to check and learn if I can optimize this better. I'll definitely see if we can have a single step for checking out kernel-src-tree, checking out kernel-container-build, etc.