ci: Introduce GitHub Actions for Firmware Build and Release

[lucaam]

This PR introduces GitHub Actions workflows to automate the build and release process for ESP32 and ESP8266 firmware.

What it does:

• Builds for both ESP32 and ESP8266 boards (optional).
• Dynamic creation of secrets.h during the build.
• Conditional artifact uploads for valid tags.
• Automatic release creation with firmware binaries attached when a new tag is pushed.

[BrookeDot]

Would it make sense to also export out the config file, there are a bunch of basic things in there I have changed such as timezone an weather location. These could likely be moved to secrets.h at some point and have it renamed config.h.

[lucaam]

@BrookeDot I would keep the idea for a separate PR allowing a config_override.h or something like that to set the basic config.h and if needed and specified, what's inside the override file.

[BrookeDot]

I totally see where you're coming from @lucaam, I guess my question was more trying to answer if the project was particularly useful without any customization in the config.

At the moment, there are a lot of little things that must be configured to make the the hack useful out of the box. I still see value in having the binary files configured, but think for 90+ percent of users they will still need to build from source to have the project meet the average use case.

The other option would be to build an access point into the project allowing configuration to occur there.

With all that said, it's cool to see how to add CI builds to C++ projects, and appreciate the work you put into this. I agree that there is no real harm in pushing the builds "as is" to the repo and then each end user can at least have an easy way to do a test on if it works or not with their hardware.

[lucaam]

Hi @BrookeDot, the main idea was add a check that just builds the project to verify that at least it builds with the changes from the pull requests, and the idea was mainly because (I don't know the history of the project) I tried to build for esp8266 and it was not working out of the box.

About the compiled binary with no configuration, as you already said, it was meant to have some kind of ready binary to let the user test it on its board, and not have the final version of the software to use. I agree with you and that's why the binary release process will be up to the maintainer since it will be triggered with tags only.

I will try to work on some kind of page to show after the first startup so the pre-built binary could also be used at that point.

[BrookeDot]

Ah that makes more sense! I have seen folks have build issues so love to have a build test that runs on commit to main for quick testing and build confirmation. Thanks for helping me understand the goals here :D

[ph1p]

I also think this is a nice addition :) thank you! Even if the builds are very different for many users, it's nice to at least get some feedback for code changes.