I've been maintaining an arduino library for a few years now. It is mainly targetting ESP8266 and ESP32 boards. It relies on the WifiClient and HTTP libraries. However, users with different target platforms (e.g. WEMOS, NodeMCU 0.9/1.0, DevKitM, etc) and library version experience problems. I have a hard time testing this and sometimes even have conflicting interests. For example, I use http.begin(*wifiClient, _ip.c_str(), _port, url.c_str());, which works fine on my NodeMCU, but on a WEMOS it just silently fails (I get http code 200, but I only get empty results) - turns out I need to use http.begin(*wifiClient, "http://" + _ip + _port + url); instead. Another example is that I used to get all the content of a http request with http.getString() in the past, which apparently is not in line with latest library standards (besides eating a lot of memory), so I switched over to using wifiClient->Stream instead, which now leads to silent failure for some users (dependent on platform and/or http/wifiClient library versions?).
I already have a bunch of #if defined(ESP8266) statements, but that doesn't ensure certain boards or library version. Since it doesn't cause problems at compile time either, my CI also can't catch it. I ofc also don't have tons of dev boards around to try all possibilities.
So in short: what is the best approach to make sure 'it works for everyone'?
This sort of runtime behavior testing definitely a challenge with embedded systems. The ideal would be to have an automated "hardware-in-the-loop" test system. Of course that would generally (the exception being HIL simulation) require hardware, which I see you don't have:
One solution for this specific component of the problem would be soliciting donations of hardware. If the users (or even hardware manufacturers) really want proper support for their hardware, they should be willing to give you the resources you need to make that happen.
The other requirement is time; either to set up and maintain an HIL system that allows for automated testing, or to perform manual testing. If you are short on that resource, you might recruit beta testers from the community. Some things you could do to encourage beta testing:
Add a clear "call to action" in the project documentation
Provide instructions for installing and updating the development version of the library
Set up "issue templates" in your repository to facilitate reporting
There is a tool available for automatically determining the memory usage impact of a proposed change to the code across the range of supported boards:
Since you are already skilled in the use of GitHub Actions, you should find it fairly easy to set it up in your repository. If you decide to give it a try and have any questions or problems, I'll be happy to provide assistance.