[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.

[Copilot]

The variable names BUILD_TIME_X86, TOTAL_TIME_X86, PASSED_X86, and FAILED_X86 are misleading when the architecture might be aarch64 only (see lines 823-828 where these same variables are used for aarch64 data). Consider using generic names like BUILD_TIME_PRIMARY, TOTAL_TIME_PRIMARY, etc., or renaming them conditionally to avoid confusion when debugging single-architecture aarch64 builds.

[Copilot]

In the single-arch case, the script uses BUILD_TIME_X86_READABLE and PASSED_X86 variables even when ARCH might be "aarch64" (see workflow lines 823-828). This creates a mismatch between what the architecture actually is and the variable names being used. The script should use conditional variable names or generic names to accurately reflect the architecture being displayed.

[Copilot]

The error message validation logic checks if the argument count is either 8-9 or exactly 13, but the comment says "8-9 for single arch" which suggests 8 and 9 are both valid. However, looking at the usage, position 9 is the optional commit_message_file which has a default value. The validation should clarify whether 8 or 9 is the expected count, or document why both are acceptable.