[github-actions] Add multi-arch support

[shreeya-patel98]

Extended the kernel build and test workflow to support multiple architectures.
The workflow now builds and tests kernels for both x86_64 and aarch64 platforms in parallel.

Important changes :-

• Renamed workflow from kernel-build-and-test-x86_64.yml to kernel-build-and-test-multiarch.yml
• Added dynamic matrix generation based on architecture input parameter
• Separate runners for each architecture (kernel-build for x86_64, kernel-build-arm64 for aarch64)
• Per-architecture artifact uploads and comparison results
• Architecture-specific kselftest baseline tracking and regression detection
• PR creation includes results from both architectures with separate status sections

[Copilot]

Pull request overview

This PR extends the kernel build and test workflow to support multiple architectures (x86_64 and aarch64) by introducing dynamic matrix generation and parallel execution across architectures.

Changes:

• Renamed workflow file from kernel-build-and-test-x86_64.yml to kernel-build-and-test-multiarch.yml with architecture input parameter
• Converted build, boot, test-kselftest, and compare-results jobs to use dynamic matrix strategy based on enabled architectures
• Updated artifact naming to be architecture-specific and modified PR creation logic to aggregate results from both architectures
• Modified create-pr-body.sh script to handle both single-arch and multi-arch reporting formats

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
.github/workflows/kernel-build-and-test-multiarch.yml	Adds matrix-based multi-arch support with dynamic architecture selection, separate runners per architecture, and consolidated PR creation with per-architecture results
.github/scripts/create-pr-body.sh	Updates PR body generation script to handle both single and multi-architecture parameter formats with conditional formatting

Comments suppressed due to low confidence (9)

.github/workflows/kernel-build-and-test-multiarch.yml:283

• The base_branch output should be architecture-specific or handled differently. Since this is now a matrix job, each architecture instance will try to set this output, but only one value will be retained. If the base branch detection logic differs or if one architecture fails while another succeeds, this could lead to inconsistent or missing output values in the create-pr job.
  .github/workflows/kernel-build-and-test-multiarch.yml:550
• The regression detection logic checks if comparison_status equals "failed" for each architecture, but the comparison_status outputs from the matrix job will be unreliable (see comment on lines 284-285). Even if that were fixed, this logic doesn't account for the case where a comparison might not exist for a particular architecture (empty string vs "skipped" vs "failed"). The conditional should explicitly check for empty strings to avoid false negatives.
  .github/workflows/kernel-build-and-test-multiarch.yml:285
• The approach for handling outputs from matrix jobs is problematic. Matrix jobs cannot reliably set job-level outputs for individual matrix instances - only the last matrix job to complete will have its outputs available. This means:

1. If x86_64 completes last, comparison_status_aarch64 will be empty regardless of its value
2. If aarch64 completes last, comparison_status_x86_64 will be empty regardless of its value

This will cause the regression detection logic in the create-pr job (lines 536-550) to fail silently. Consider using artifacts to store comparison results instead, or restructure the workflow to have separate comparison jobs per architecture that don't use matrix.
.github/workflows/kernel-build-and-test-multiarch.yml:728

• This appears to be referencing a development branch 'shreeya_kernelci_main' instead of the main branch. This is likely a mistake and should be reverted to fetch from 'main' to ensure the workflow uses the stable version of the script. Using a personal/development branch in production workflows creates maintenance and stability issues.
  .github/workflows/kernel-build-and-test-multiarch.yml:814
• The logic for passing parameters to the script when both architectures are enabled is unclear and potentially incorrect. The script expects 13 positional parameters for multi-arch (architecture, build_time, total_time, passed, failed, run_id, comparison_section, repo, commit_message_file, build_time_aarch64, total_time_aarch64, passed_aarch64, failed_aarch64), but the script invocation at lines 832-843 doesn't align properly with this expectation. The EXTRA_PARAMS variable is appended at line 842, but it's a space-separated string which could be interpreted as multiple arguments. This needs to be restructured to properly pass all 13 arguments in the correct order.
  .github/workflows/kernel-build-and-test-multiarch.yml:278
• The condition checks only for exit status success() or failure(), but doesn't handle the skipped or cancelled states. If test-kselftest is skipped for any reason, the compare-results job will still run, which might not be desirable. Consider being more explicit about when this should run, e.g., 'if: always() && needs.test-kselftest.result != 'cancelled''.
  .github/workflows/kernel-build-and-test-multiarch.yml:391
• The workflow references 'kernel-build-and-test-multiarch.yml' at line 391, but this is checking against past runs. If this workflow was recently renamed from 'kernel-build-and-test-x86_64.yml', there may be historical runs under the old workflow name that should still be considered as valid baselines. Consider checking both workflow names during the transition period to avoid losing baseline comparisons.
  .github/workflows/kernel-build-and-test-multiarch.yml:803
• The comparison status case statement doesn't handle empty or undefined values properly. If the outputs are empty (which they will be due to the matrix job output issue), the case will match the '*' wildcard and display "Failed - Regression detected" even when no comparison was performed. Add an explicit check for empty strings before entering the case statement.
  .github/workflows/kernel-build-and-test-multiarch.yml:842
• The script invocation constructs EXTRA_PARAMS as a string with space-separated values and then appends it with '$EXTRA_PARAMS' at line 842. Without proper quoting (should be "$EXTRA_PARAMS"), this will cause word splitting and the individual parameters won't be passed as separate positional arguments to the script. This breaks the 13-argument expectation for multi-arch. Each parameter should be passed separately on its own line or the string should be properly quoted.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[roxanan1996]

I find this confusing.
So arch can be x86_64,aarch64 or just one of them right?

But then, buil_time, total time etc do not seem to be arch specific based on the name, even though it is because they represent the first arch given.
Also, the optional params are named after aarch64. What if x86 is the optional arch?
I may be missing something, but I personally find this hard to read.

[PlaidCat]

I'm not sure I'm keen on the positional arguments
I asked claude to consider making a getops version, ... its a little weird and we could compress it with some level of json for each arch ... the biggest issue is making sure its all ordered correctly at the arch section.

  Option 1: getopts with flags

  ./create-pr-body.sh \
    --arch x86_64 --build-time 100s --total-time 200s --passed 50 --failed 10 \
    --arch aarch64 --build-time 150s --total-time 250s --passed 60 --failed 12 \
    --run-id 12345 \
    --comparison "comparison section..." \
    --repo "owner/repo" \
    --commit-file /tmp/msg.txt

  #!/bin/bash
  set -euo pipefail

  declare -A ARCH_DATA
  CURRENT_ARCH=""

  while [[ $# -gt 0 ]]; do
    case "$1" in
      --arch)
        CURRENT_ARCH="$2"
        ARCHS+=("$CURRENT_ARCH")
        shift 2
        ;;
      --build-time)
        ARCH_DATA["${CURRENT_ARCH}_build_time"]="$2"
        shift 2
        ;;
      --total-time)
        ARCH_DATA["${CURRENT_ARCH}_total_time"]="$2"
        shift 2
        ;;
      --passed)
        ARCH_DATA["${CURRENT_ARCH}_passed"]="$2"
        shift 2
        ;;
      --failed)
        ARCH_DATA["${CURRENT_ARCH}_failed"]="$2"
        shift 2
        ;;
      --run-id)
        RUN_ID="$2"
        shift 2
        ;;
      --comparison)
        COMPARISON_SECTION="$2"
        shift 2
        ;;
      --repo)
        REPO="$2"
        shift 2
        ;;
      --commit-file)
        COMMIT_MESSAGE_FILE="$2"
        shift 2
        ;;
      *)
        echo "Unknown option: $1" >&2
        exit 1
        ;;
    esac
  done

  # Now iterate over ARCHS array - works for 1, 2, or N architectures
  for arch in "${ARCHS[@]}"; do
    echo "Arch: $arch"
    echo "  Build time: ${ARCH_DATA[${arch}_build_time]}"
    # ...
  done

[roxanan1996]

This is a lot of duplication.

I prefer to just add 3 ifs if MULTIARCH and add the second arch there.

[roxanan1996]

This should be reverted.

[PlaidCat]

Yes everything that had main in 725 -> 728

[shreeya-patel98]

ah right, thanks for catching this.

[PlaidCat]

Everything except this is quoted please quote this.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (5)

.github/workflows/kernel-build-and-test-multiarch.yml:285

• compare-results is a matrix job, but job outputs are not reliably available per-matrix-run. The conditional outputs here will be set independently in each matrix run, and downstream needs.compare-results.outputs.* will not give you both architectures' statuses (it typically resolves to a single run’s outputs). This can cause regressions on one architecture to be missed. Consider writing per-arch comparison results to artifacts and adding a non-matrix aggregation job that downloads them and exposes stable outputs for create-pr (or split compare into separate non-matrix jobs gated by if).
  .github/workflows/kernel-build-and-test-multiarch.yml:547
• These needs.compare-results.outputs.comparison_status_* checks depend on compare-results matrix job outputs. With the current matrix setup, needs.compare-results.outputs will not reliably contain both architectures’ results, so this regression gate may incorrectly allow PR creation. Use an explicit aggregation step/job to collect per-arch statuses before evaluating REGRESSION_DETECTED.
  .github/workflows/kernel-build-and-test-multiarch.yml:690
• build_time_* / total_time_* are always suffixed with s, even when the grep fallback produces N/A. That yields values like N/As, and create-pr-body.sh’s convert_time will then fail arithmetic expansion under set -e. Either emit plain N/A (without s) or change both the workflow and script to use a numeric fallback (e.g., 0s) and/or teach convert_time to pass through non-numeric inputs.
  .github/workflows/kernel-build-and-test-multiarch.yml:728
• Hard-coding shreeya_kernelci_main as the source of create-pr-body.sh makes this workflow fragile (it will fail if that branch doesn’t exist or is renamed, and it’s unexpected in a reusable workflow). Prefer checking out the script from the current ref, the repository default branch, or a pinned commit SHA/tag so the workflow is portable and reproducible.
  .github/workflows/kernel-build-and-test-multiarch.yml:48
• The dynamic matrix generation doesn’t validate that at least one supported architecture was selected. If inputs.architectures is empty/invalid, MATRIX_ITEMS stays empty and the downstream matrix jobs won’t run, leading to confusing workflow behavior. Consider failing the setup job with a clear error when no supported architectures are detected (or normalize/validate the input list).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

convert_time assumes the input is numeric seconds and will exit the script on values like N/A (arithmetic expansion fails under set -e). Since the workflow can emit non-numeric fallbacks, make convert_time resilient (e.g., detect non-numeric input and return it unchanged) or ensure callers always pass a valid integer number of seconds.

[Copilot]

Option parsing assumes every flag has a following value (e.g., CURRENT_ARCH="$2") but doesn’t check that $2 exists. With set -u, a malformed invocation will crash with an unbound variable rather than a controlled usage error. Add explicit validation for missing option arguments (e.g., ensure [[ $# -ge 2 ]] before reading $2).