build.yml: Skip the CI Builds that don't match the Arch Label

[lupyuen]

Summary

This PR proposes to enhance the CI Workflow, to skip the unnecessary NuttX Builds. Currently, NuttX Devs wait for the CI Builds to complete across All Architectures (Arm32, Arm64, RISC-V, Xtensa), even though they modified a Single Architecture. With this PR, the CI Workflow will build only the Modified Architecture.

The solution uses the Arch Labels for PRs. We target only the Simple PRs: One Arch Label + One Size Label (e.g. "Arch: risc-v, Size: XS")

• If "Arch: arm / arm64" is the only non-size label, then we build other, arm-01, arm-02, ...
• If "Arch: risc-v" is the only non-size label, then build risc-v-01, risc-v-02
• If "Arch: xtensa" is the only non-size label, then build xtensa-01, xtensa-02
• The above rules apply when the PR is Created or Modified
• When the PR is Merged: All targets shall be built

The code is explained here: #13775

Impact

For Simple PRs: CI Builds shall be skipped for the targets that don't match the Arch Label

For Complex PRs: No change, all targets shall be built

Testing

When we create a PR, the irrelevant builds are skipped in seconds. Click "Show All Jobs" to reveal the timings: (Merge PR will compile all targets, same for Others)

• Arm32: Create PR / Merge PR
• Arm64: Create PR / Merge PR
• RISC-V: Create PR / Merge PR
• Xtensa: Create PR / Merge PR
• Others: Create PR / Merge PR

[nuttxpr]

[Experimental Bot, please feedback here]

The provided PR description mostly meets the NuttX requirements, but could use a few minor improvements:

Strengths:

• Summary: Clearly explains the problem, proposed solution, and how it works. Linking to the issue is helpful.
• Impact: Addresses all the points, highlighting the key benefit for simple PRs and maintaining existing behavior for complex ones.
• Testing: Provides multiple examples with links, demonstrating the intended behavior in various scenarios. Clearly distinguishes between PR creation and merging.

Areas for Improvement:

• Testing:
  • Before Change Logs: While you mention "the irrelevant builds are skipped in seconds," providing actual "before" logs, even if they just show the numerous builds being triggered, would offer a direct comparison point.
  • Build Host/Target Details: Specify the host OS, compiler, specific target boards, and configurations used for testing. This adds credibility and helps reviewers reproduce your results.

Conciseness:

• The description is already quite concise. You could potentially shorten the "Testing" section by summarizing the results instead of listing each architecture separately, especially since the links provide the details. For example:

  "Testing confirms that irrelevant builds are skipped in seconds when creating a PR with a single architecture label. This has been verified across ARM32, ARM64, RISC-V, and Xtensa architectures (see links for detailed logs). Merge PRs and PRs without clear architecture labels continue to build all targets as expected."

Overall:

This PR description effectively conveys the necessary information. Adding the "before" logs and some specific build details would further strengthen it.

[xiaoxiang781216]

should we optimize sim arch too?

[lupyuen]

should we optimize sim arch too?

@xiaoxiang781216 Yep I'll do this in the next PR. Right now I'm keen to monitor the effect of the updated CI Workflow, to make sure that we comply with the ASF Policy for GitHub Actions.