Check packages with nightly for RISC-V devices

[SergioGasquez]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• My changes are in accordance to the esp-rs API guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

Description

Adds a nightly job which can fail that builds and lints the packages for RISC-V devices with nightly channel. I've added the job in the same workflow, as the total time got a bit better (~15 mins to the current ~ 17, and we are now on 21 jobs but rustfmt job is really fast), happy to move into a standalone workflow if we think its better.

Testing

CI Run: https://github.com/SergioGasquez/esp-hal/actions/runs/10157891170

[jessebraham]

IMO if this is how we're going to structure the workflow then we should extract the common bits into a local action. There is a ton of duplication right now and I can almost guarantee the two jobs will fall out of sync eventually.

[MabezDev]

I agree with Jesse, in fact we already have the nightly toolchain on the normal esp-hal job:

esp-hal/.github/workflows/ci.yml

Line 81 in 81f3776

- uses: dtolnay/rust-toolchain@v1

we just need to add the appropriate sections for changing to the nightly toolchain via the xtask (maybe we can make this possible to change via env, might make this easier to accomplish?)

[SergioGasquez]

Ive just squashed the nightly and esp-hal jobs into a single one by increasing the matrix (I was working on this before reading the feedback on this PR 😓), not sure if its worth to add an action now that the steps are not duplicated

[MabezDev]

not sure if its worth to add an action now that the steps are not duplicated

By doing it the way I suggested, can we still allow the nightly steps to fail? If not then we likely will need to split it into a separate action and re-use.

[SergioGasquez]

Should be possible to fail on nightly by adding the extra matrix arg, just updated it. Example CI run: https://github.com/SergioGasquez/esp-hal/actions/runs/10164106747

[jessebraham]

Also curious, we had previously discussed just running the nightly checks once per day rather than for each CI workflow run. Why have we decided to deviate from that plan?

[SergioGasquez]

Also curious, we had previously discussed just running the nightly checks once per day rather than for each CI workflow run. Why have we decided to deviate from that plan?

AFAIK, we didn't reach a decision, so I experimented with this approach but, as mentioned in the PR description, I'm happy to move into another workflow. I don't have any hard preference, but what could happen is that we completely ignore the nightly workflow (which can also happen with having it included in the main workflow, but could be easier to check)

Also, just noticed that if we end up going this approach we should update the required checks as it now includes the toolchain in the job name.

[SergioGasquez]

Added a new workflow for the nightly checks and gathered the common logic into an action. Here is a run of the nightly CI: https://github.com/esp-rs/esp-hal/actions/runs/10267836036

[MabezDev]

LGTM, thanks!

[jessebraham]

Sorry this is kind of nit-picky, but I am not a huge fan of the name check-packages for the action, as it only actually checks esp-hal and this is kind of confusing when reading through the workflow.

[SergioGasquez]

Sorry this is kind of nit-picky, but I am not a huge fan of the name check-packages for the action, as it only actually checks esp-hal and this is kind of confusing when reading through the workflow.

Agree, the name was confusing, Im not happy with check-esp-hal either as it also checks esp-lp-hal, but its a better name for the moment, if we have any better suggestion Ill update it

[jessebraham]

Thanks for this!