More Forgiving Handling of Failed Build

[FoamyGuy]

This issue is motivated by an issue that arose recently with one of the libraries in the community bundle.

A change to that library caused the bundle-build for the community bundle to fail https://github.com/adafruit/CircuitPython_Community_Bundle/actions/runs/10969895769/job/30463140170#step:8:42

The project bundling system used by Learn was impacted initially when the builds started failing as well, but mitigation has been put in place there.

It would be nice if the build-tool could note the failure to build whatever specific library failed, but also continue on and build the rest of the bundle to the best of it's abilities, leaving an error note or perhaps old version in the zipped bundle for any libraries that fail.

This graceful handling could be limited to the community bundle, or any others where the libraries are not owned / maintained directly by Adafruit if we wanted, so that the mechanism could still serve as a warning of a problem in Adafruit repo's that we have the ability to repair more quickly with direct access.

[jepler]

Here's what I understand about the situation that occurred

• some library was previously added to the community bundle. This went via the PR process, and the PR was green
• the library does not use standard CI from cookie cutter, so when a change was made that violated our rule "Multiple top level py files not allowed" this was not detected in the library
• later, the library made a tagged release. Adabot automatically incorporated this tagged release directly into the main branch, bypassing the PR process and CI checks
• adabot doesn't run CI-like steps locally either to verify the new versions are good
• the community bundle couldn't be built
• this had knock-on effects such as failure of Adafruit's internal "bundlefly" tool to build any project bundles, whether or not the project depended on a library from the community bundle

besides adding this flag to "do our best and produce a bundle with some files in it", can we improve the process so that this is less likely to occur in the future?

Here are some ideas that I had, though they require either additional coding or additional human actions when accepting a new library:

• make it a requirement that a library in the community bundle uses the standard cookiecutter actions
• before accepting a library into the community bundle, verify that standard cookiecutter actions are in use
  • a library could still disable them later
  • a library might not incorporate updates to the actions when we make them in cookiecutter
  • a library might release when CI is red, knowingly or unknowingly
• adabot should build the bundle locally (i.e., during its CI run within the adabot repo) before pushing to main and fail loudly otherwise, though this holds back all other updates within the bundle when any library is failing in its latest version

[jepler]

I'm also uneasy about applying the "skip_failed" flag during circuitpython-build-tools own CI process. Instead, it might be preferable to specify an explicit revision of the test bundle to build, one that is known not to have problems, and leave this flag off during the CI here.

[tannewt]

• adabot should build the bundle locally (i.e., during its CI run within the adabot repo) before pushing to main and fail loudly otherwise, though this holds back all other updates within the bundle when any library is failing in its latest version

This sounds best to me. Don't update the bundle if any of the deps fail. Maybe add a "disable" option for libraries that cause issues so we can manually unblock the bundle.

[jepler]

@FoamyGuy can you please add the "test-build before pushing" behavior in Adabot as part of your Adafruit work? I've added adafruit/adabot#377 to track it.

[FoamyGuy]

Yes, I'll take a look into this today.

[FoamyGuy]

This is resolved by: adafruit/adabot#378