[Testers Needed] Building PRs in Our Own Repos

[lupyuen]

Description

We're testing a new way to Build PRs in Our Own NuttX Repos, wonder if you would like to try out, and give your feedback to @simbit18 and me? Thank you so much :-)

1. Demo Video in YouTube
   Demo Video in Google Drive
2. Browse to github.com/NuttX/manual-nuttx-ci
3. Click "Fork" to clone the repo
4. Click "Actions > Enable GitHub Actions"
5. Click "Manually Build NuttX > Run Workflow"
6. Enter the info below. Suppose we are building this PR
   arch/arm64/imx95-a55: add GPIO and eMMC (USDHC) support with partition table parsing #18501, which comes from github.com/jasonbu/nuttx/tree/imx95_emmc8bit
   • Repo for NuttX: jasonbu/nuttx
   • NuttX Branch: imx95_emmc8bit
   • Repo for NuttX Apps: apache/nuttx-apps
   • NuttX Apps Branch: master
   • Host Platform: all
7. And the PR Build should start. Lemme know if it doesn't work thanks!
8. Why are we doing this? Earlier this year, we saw very high usage of GitHub Runners. By building PRs in Our Own NuttX Repos, we will greatly reduce our usage of GitHub Runners, so that ASF Infrastructure Team won't revoke our access to GitHub CI. So we hope everyone can help out thanks :-)

We're waiting for feedback from these testers:

• arch/arm64/imx95-a55: add GPIO and eMMC (USDHC) support with partition table parsing #18501
• WIP: initial support for fixed-point data for sensors #17408
• !boards: Simplify NuttX initialization #18408

Verification

• I have verified before submitting the report.

[simbit18]

We have added a second workflow for building a <board name>:<board configuration> using Make and CMake

1. Click "Actions > Enable GitHub Actions"
2. Click "Manually Compiling with Make or Cmake for test > Run Workflow"
3. Enter the info below. Suppose we are building this sim:nsh
   • Repo for NuttX: apache/nuttx
   • NuttX Branch: master
   • Repo for NuttX Apps: apache/nuttx-apps
   • NuttX Apps Branch: master
   • Config: sim:nsh
   • Build system: all
4. And Build should start.

[Laczen]

Hi @lupyuen, don't know if it is possible, but could this be done on a forked Nuttx. So that after a branch is pushed I can build NuttX CI it on my fork and only create a PR when the build NuttX CI is succesful?

[simbit18]

@Laczen Yes, that is precisely the purpose of this repository github.com/NuttX/manual-nuttx-ci
NuttX/manual-nuttx-ci#1 (comment)

[Laczen]

@Laczen Yes, that is precisely the purpose of this repository github.com/NuttX/manual-nuttx-ci NuttX/manual-nuttx-ci#1 (comment)

Maybe I was not clear enough. I meant making this workflow a part of the NuttX fork that I already have.

[simbit18]

If the branch is on GitHub, then it’s possible
example branch esp32_simpleboot:

Repo for NuttX: Laczen/nuttx
NuttX Branch: esp32_simpleboot <- This could be any of your new branches
Repo for NuttX Apps: apache/nuttx-apps
NuttX Apps Branch: master
Host Platform: all

[tmedicci]

Amazing work, @simbit18 and @lupyuen !

Suggestion: It'd be nice to be able to set env vars to build NuttX (I'm not sure if we'd need to tweak our CI tools or it could be set directly on job).

For instance, being able to set ESP_HAL_3RDPARTY_URL to ongoing development.

[simbit18]

Hi @tmedicci, I understand your request, and we could consider adding another workflow for Espressif.

However, if we add the option to modify the ESP_HAL_3RDPARTY_VERSION environment variable, all of these architectures

• arch/risc-v
• arch/risc-v/src/esp32c3-legacy
• arch/xtensa/src/esp32
• arch/xtensa/src/esp32s2
• arch/xtensa/src/esp32s3

will use the same Git hash, but as far as I can see, that is not currently the case, so some jobs will fail.

[tmedicci]

Hi @tmedicci, I understand your request, and we could consider adding another workflow for Espressif.

I don't think we need something specifically for Espressif. We can set any environment var to the build system. There are a couple of them that "tweaks" the build system.

However, if we add the option to modify the ESP_HAL_3RDPARTY_VERSION environment variable, all of these architectures

* arch/risc-v

* arch/risc-v/src/esp32c3-legacy

* arch/xtensa/src/esp32

* arch/xtensa/src/esp32s2

* arch/xtensa/src/esp32s3

will use the same Git hash, but as far as I can see, that is not currently the case, so some jobs will fail.

There are a couple of things to consider here:

1. ESP_HAL_3RDPARTY_VERSION isn't usually set because the PR itself already contains the version being tested. Just setting ESP_HAL_3RDPARTY_URL is enough to test an under-development branch (yet not yet published, for instance).
2. However, we always keep it aligned: when we update the version, we do that for every supported chip (xtensa update is on the way). An exception to that is esp32c3-legacy, which is expected to be removed in a major NuttX release.

[tmedicci]

Another useful feature would be being able to select which set of tests are expected to run manually. For instance, selecting just xtensa-01 or a set of .dats.

[simbit18]

@tmedicci Thank you for your feedback; we’ll do our best to improve.

[tmedicci]

Apparently, there is a 2h timeout for the jobs: https://github.com/tmedicci/manual-nuttx-ci/actions/runs/23606479413/job/68750649341#step:10:1334

Is this set by NuttX or the CI?

[tmedicci]

Apparently, there is a 2h timeout for the jobs: https://github.com/tmedicci/manual-nuttx-ci/actions/runs/23606479413/job/68750649341#step:10:1334

Is this set by NuttX or the CI?

Just checked that it's being set here. I increased it on my fork. Perhaps we should increase it because GH-provided runners for regular users might not be as fast as the ones we get from ASF.