Open dlamkins opened 4 years ago
I propose that the items following should be automated when a user PRs a new module package manifest. Any test failures would consequently block merging until resolved.
.bhm
is not flagged after scanned.Other potential items:
.bhm
file matches what is expected of a module (contains a manifest, the DLL name matches the package name listed in the manifest, etc.Some of these items are inspired by the automation utilized in the winget-pkgs repository for their submission validation.
We could additionally check if the latest supported bhud crashes when the bhm with all its dependencies gets loaded. It would be a lot of work to implement this though.
I absolutely see value to that, so I don't want to discount it, but you're right — it would be some extra work. I suspect that is something we could implement down the road, though.
The first implementation of this is complete.
It is not yet triggered automatically, but does cover the following tests:
It also hosts decompiled source and ref contents in a repo to make reviewing code changes easier.
Automation through CI should be the primary method of PR review to ensure a minimum level of quality in submitted manifests, reduce the chance for human mistakes, and reduce the workload of reviewers.