Compile example reusable wflow

[jaenrig-ifx]

By creating this pull request you agree to the terms in CONTRIBUTING.md.
https://github.com/Infineon/.github/blob/master/CONTRIBUTING.md
--- DO NOT DELETE ANYTHING ABOVE THIS LINE ---

CONTRIBUTING.md also tells you what to expect in the PR process.

This is the proposal for reusable compile-examples workflow for libraries:

• Added reusable "Compile library examples" workflow from "arduino-devops" -> https://github.com/Infineon/arduino-devops/blob/compile-examples-lib/.github/workflows/compile-examples-lib.yml.

  • The workflow will scan the "fqbn" matrix and create a job for each of the of the boards.
  • Then it will install "arduino-cli" and the required core for the "fqbn"
  • Finally, the relevant "sketches " (by default all the examples of the library) will be compiled against each "fqbn"

• The "ci-matrix-config.yml" file is optional. If not added to the project, the default "fqbn" matrix will be used -> https://github.com/Infineon/arduino-devops/blob/compile-examples-lib/config/ci-config-matrix-ifx-lib.yml

• In this case, the "ci-matrix-config.yml" is used, to extend or modify the default Infineon "fqbn" matrix for libraries. Specifically, we have added the esp32 board which was added in the previous build check, and exclude from the sketch-fqbn combinations which are not supported.

Open questions to @ederjc :

• Unlike the cores, this workflow is only running on ubuntu. I don´t think is relevant to check multiple OS for libraries. Agree?
• This is currently installing the cores (our cores arduino-core-psoc6 and xmc-for-arduino) through the arduino-cli. This means that we are consuming release assets downloads in ci, affecting the user download numbers. I expect that currently the libraries are not exhaustively running these workflows (we will run them monthly or so?), and we can live with that "adulteration" of downloads.
  We can implement that mechanism, but we can maybe reuse the flow we implement for release candidates check. What do you think?

I need to cleanup and document the scripts in "arduino-devops". Meanwhile I keep this as draft.

[Copilot]

Pull Request Overview

This pull request introduces a reusable workflow for compiling library examples by integrating the "Compile library examples" workflow from arduino-devops and providing an optional configuration file (ci-matrix-config.yml) to extend the default fqbn matrix for libraries. Key changes include:

• Adding a ci-matrix-config.yml file that includes an esp32 board, defines exclusions for certain sketches, and adds an additional URL for core installation.
• Creating a compile_examples.yml workflow that reuses the compile-examples-lib workflow from the Infineon/arduino-devops repository.

Reviewed Changes

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

File	Description
ci-matrix-config.yml	Adds custom inclusion and exclusion rules for board fqbn configurations and additional URL for esp32 core setup
.github/workflows/compile_examples.yml	Introduces a reusable workflow that leverages the compile-examples-lib workflow from the Infineon/arduino-devops repo

Files not reviewed (1)

• .github/workflows/build-check.yml: Language not supported

[ederjc]

Unlike the cores, this workflow is only running on ubuntu. I don´t think is relevant to check multiple OS for libraries. Agree?

I would say we start like this and see if it's sufficient. I assume yes.

This means that we are consuming release assets downloads in ci, affecting the user download numbers.

This is fine. Our main metric is based on repo views, not release download numbers.

Why are secrets needed for this workflow?

[jaenrig-ifx]

Unlike the cores, this workflow is only running on ubuntu. I don´t think is relevant to check multiple OS for libraries. Agree?

I would say we start like this and see if it's sufficient. I assume yes.

This means that we are consuming release assets downloads in ci, affecting the user download numbers.

This is fine. Our main metric is based on repo views, not release download numbers.

Why are secrets needed for this workflow?

Let me check if that is needed :)

[ederjc]

Before merging this, can you please have a look at these workflow call conditions?
Please apply this also here or recommend a better approach.

Requirements:

• a scheduled run
• option to call manually (workflow_call:)
• on certain actions like push, tag, PR -> here you know better what's best.

[jaenrig-ifx]

Before merging this, can you please have a look at these workflow call conditions? Please apply this also here or recommend a better approach.

Requirements:

• a scheduled run
• option to call manually (workflow_call:)
• on certain actions like push, tag, PR -> here you know better what's best.

I will add them, but directly to this wflow (as they are not meaningful or possible in the reusable wflow):

• schedule run -> yes
• I think you mean workflow_dispatch -> yes
• We can do:
  • push on "master" and "tag"
  • PR to "master"
    That way we skip the wflow to run for every commit on a development branch. Which can be a bit abusive. Do you agree?

I think we can get rid of the "develop" branch or?

[ederjc]

I think you mean workflow_dispatch -> yes

Yes, I do mean workflow_dispatch and apparently got this wrong in my reference.

PR to "master"
That way we skip the wflow to run for every commit on a development branch. Which can be a bit abusive. Do you agree?

Did you look into the reference file above? My recommendation from there:

• push: only master/main
• PR: all branches
• tags: all

What's your recommendation?

I think we can get rid of the "develop" branch or?

Yes.

[ederjc]

👍