CI Improvements - Part 1

[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

• HIL workflow: Fix the condition to erase flash when tests fail. Source
• Remove path-ignore to avoid CI not being triggered.
• Build documentation

Testing

• The HIL workflow cant be tested easily, we need to monitor the workflow and verify that upon a test failure, the erase-flash step is executed.
• Documentation was built in my fork https://github.com/SergioGasquez/esp-hal/actions/runs/9972410348/attempts/1. I ran the workflow twice, both took ~10min45. Currently, CI takes between 10 to 14 mins, so I guess we didn't increased it too much.
  • Happy to move this to a nightly CI workflow, but it looks like it doesnt add much time.

[bjoernQ]

LGTM - I don't really understand the fix for the flash-erase but that's most probably a lack of knowledge about GitHub workflows on my side

[JurajSadel]

LGTM, thanks!

[SergioGasquez]

LGTM - I don't really understand the fix for the flash-erase but that's most probably a lack of knowledge about GitHub workflows on my side

I don't fully understand it either, but it wasn't working before and the GH docs has an example using that same condition

[MabezDev]

Thanks, this is a nice improvement!

[AnthonyGrondin]

For the flash-erase fix, it seems to be because Github's implementation require failure() to be present in the if statement, else it automatically uses success()

failure with conditions 🔗
You can include extra conditions for a step to run after a failure, but you must still include failure() to override the default status check of success() that is automatically applied to if conditions that don't contain a status check function.