Add date and time into wled-ci.yml output files for beta testing

[dosipod]

This is not an issue but opened here due to "Discussions" not being available which it should as some of the active devs do not visit discord and some of the questions opened as issues are closed without clear answer other then that it is not a bug or not planned . If discussions is enabled then that would be a community effort that does not necessarily need a dev involvement .

To start it off I am trying to add date and time to the builds both zip and bins , this is needed as I am trying to test a lot and I get confused as to which files to use as the file generated from github is having the same name , would also help us go back to specific date or time we built in , I tried to add that with date variable to wled-ci.yml but I could not get that to work correctly . The https://wled-compile.github.io/ yaml has date example but written to a file if that is a good place to start.

This is just for us to help test in a more organized way and might be specific question to @willmmiles or @softhack007 . Otherwise I might try to bug @wled-install for it

Cheers

[willmmiles]

To confirm my understanding of the problem you're trying to solve:

• By default, the output binary name in the build_outputs/release folder lists only the "base" version, and target environment.
• This creates two issues:
  • It is not possible (or at least impractical) to distinguish "clean" builds of the release tag from development or testing builds with additional patches
  • The filename does not capture which options are enabled without creating a custom environment
• This problem is made worse when using Github codespaces or CI for development, as the build output files collect in the downloads folder with unhelpful filenames, like WLED_0.15.0-b6_ESP32_WROVER (3).bin.

Is this correct? I've definitely had trouble with keeping track of which build came from where, particularly when I'm slinging a bunch of experimental branches around.

Sorry if I seem like I'm being a bit pedantic - I want to make sure I fully understand the problem before looking at solutions.

[dosipod]

Yeah you got the idea and I am really on 101 when it comes to github and just started yesterday looking at the scripting in wled-ci.yml .

The end goal is for the name to have the output of something like the command date +"%FT%H%M" , so the file would be named 2024-10-28T1522_WLED_0.15.0-b6_ESP32_WROVER.bin or the zip file will also have the date .Since you also had trouble with keeping track of which build came from where I would not show you my folder for testing which is having a ton of files that is useless as I no longer know the point in time I built on and have to flash bins to see the version .

[blazoncek]

I've managed to come up with (partial) solution to automatically create build stamp. set_version.py

Import('env')
import json
import datetime
t = datetime.datetime.now()
env.Append(BUILD_FLAGS=[f"-D VERSION={t.strftime('%y%m%d')}0"])

PACKAGE_FILE = "package.json"

with open(PACKAGE_FILE, "r") as package:
    version = json.load(package)["version"]
    env.Append(BUILD_FLAGS=[f"-DWLED_VERSION={version}"])

Comment out #define VERSION 2410270 in wled.h and add

WLED_GLOBAL unsigned build       _INIT(VERSION);

Then replace VERSION with build in source files.

Unfortunately all builds will have 0 as I do not know how to increment that each time when building sources.

VERSION can be used to append to filename. That's in output_bins.py.

[willmmiles]

There are a few problems that will come up with just straight embedding build timestamps in variables and filenames:

1. Builds are not reproducible anymore -- if you check out the same source code, you get something different.
   • It can be worse than just "some string is slightly different" - changes to the string length can affect the layout in memory, and that can impact how many instructions are needed to load things in functions... it snowballs fast
   • This can be somewhat mitigated by disabling this behaviour for release builds
2. Unbounded growth of output folders. If you do a lot of compiles, you can end up with hundreds or thousands of old builds kicking around that need to be cleaned out periodically.
3. It'll break PlatformIO's object file caching. If the build data is passed in via a compiler flags, eg. '-D VERSION=my_build, it'll be recompiling everything all the time.
4. Build timestamps actually tell you basically nothing about the build. I don't always remember which order I built things in, I don't know about anybody else.

In the past I've built something based on parsing git metadata, eg. git describe -- it'll tell you the branch or tag, how many commits past it, give the actual commit hash, and indicate if there are uncommitted changes. This solves problems 1 and 4, above, with the caveat that if you ever care to roll back or re-read some specific code, you need to commit it first. (This is best practice anyways as debug code can be squashed away later).

I'm pretty sure we can work around problem 3 with some extra logic in the platformio hooks. We'd probably want to isolate the version data to its own object file, and then override the build flags just for that one file.

I can live with problem 2 being an exercise for the developer for the time being. It won't bother CI, at least.

I can look at this in more detail in a week or two. I am somewhat backlogged with halloween stuff at the moment.

[DedeHai]

If the issue is only the file names: isn't there the option to run a post build script? Could that be used to just rename the files and add a timestamp? that would leave the actual build untouched.

[blazoncek]

I've also experimented with git rev-parse --short HEAD which will give you commit hash, which can be good as you know from which commit it was built from, but it cannot solve every aspect.

As for filenames, WLED_RELEASE_NAME is the one to modify if you want different binary name. But again that is static and you cannot tell which build it was from.

[netmindz]

I'll try and send a longer explanation later, but in short I would say do not change anything about the actual build itself, only the naming of it artifact that are produced by the CI, I typically name these either based on the githash for non-tags and also include the branch name too

Example

https://github.com/MoonModules/StarLight/actions/runs/11561069229

[willmmiles]

I'll try and send a longer explanation later, but in short I would say do not change anything about the actual build itself

I'd definitely like to hear more about your experiences here -- I was really hoping to embed the build details in the binary, so we can definitively map debug reports to specific builds. I use Ghidra a lot for digging through stack traces and core dumps, and matching the exact binary used is critical.

[dosipod]

Piece of cake

https://github.com/dosipod/WLED_15/blob/unfrezz_fix/.github/workflows/wled-ci.yml @willmmiles happy halloween