-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
USERMODS compile branch #4466
Comments
Yeah that's a nice idea. That's kinda what we have in MM with the XL build target |
IMO more important decision is whether to include some usermods as a standard feature (even though using usermod API) and take care of those usemods by core/team members or not. If not, leave as is but require usermod submitter to provide contact information and/or support. If yes, be prepared to acquire all necessary hardware and do testing after each core modification that requires update in usermods. Another topic (that I partially started some time ago) is pruning of existing inoperable/stale usermods. |
100% with blazoncek on this one. Who will have all the hardware (and all the time) to test it and hunt for bugs? even if something compiles does not mean it works. |
I agree with @dosipod that ensuring compilation fails are caught by CI is a good thing. That is not however the same thing as us releasing a bin that has these usermods included |
can this be done by adding a branch with a different platformio.ini that does a compile for a combination of UMs on all ESP flavours or is there a more clever way? There are 54 usermods... so thats a ton of configurations. |
Can't be a branch as you want PR branches to run this. It would be a special platformio-override.ini that the CI script would use Ideally generated using a script to ensure it covers all usermod including new ones just created in that PR |
See example here of a build doing what I think you were looking for @dosipod |
At the moment I'm just testing all usermods in single build for esp32. We can then extend this in the CI to use a matrix build where we do all usermods for all hardware platforms. We could also do a build that was only a single usermod for each platform to be sure of catching all the dependencies needed for a single usermod, but that would definitely only be used in special cases, not every push |
The aim is to make sure changes to source does not fail usermods or those failures are known ,that does not mean it has to be fixed by the team even if it fails .If major changes to source could be done in such a way not to fail the usermods then it is good but I think that might not possible in all cases @blazoncek @DedeHai , is this something you agree on ? I have already setup a test repo with a simple platformio.ini following the exact instructions in every usermod as we are also trying to fix the usermods compile issues , readme , contact the owner ..etc but only for some of them on esp32 . @netmindz Migrating the usermod seems a step further and if you see that with the guys to be positive then sure we are onboard , do you have branch already where we could see the failures ? |
The idea of usermods is great but lately it is becoming an issue with each new release to see which usermod fails when the change is from source and not in the usermod related code .
Why not create a branch with an environment enabled for each usermods at least for esp32 to confirm they would compile so the owner would know and others could step-up to fix them .
If so we could setup such platformio.ini and even if there is no fix for the failed usermod at least that would still be a reminder of those issues .
Unfortunately we cant compare to other projects like tasmota as there is no concept of usermods but still if you look at the daily build you would see builds for features such as BLE and others .
The text was updated successfully, but these errors were encountered: