Better procedure for tracking firmware binary releases vs. code commits #7
Description
During the current cruises's debugging, we have wound up with a number of .elf files floating around without a clear mapping to the code used to generate them. This makes debugging harder.
We should come up with a procedure that associates tags in the firmware repository with .elf files that make it into the wild.
I think the threshold for tracking needs to be lower than "anything pushed to main in the binaries repository" -- I'd suggest putting the threshold at "any time a .elf is pushed to a non-development microSwift".
For now, what we've started doing is putting debug builds in a branch in the binaries repo:
https://github.com/SASlabgroup/microSWIFT-V2-Binaries/tree/troubleshooting_obs/V2.2
And adding a tag to the firmware repo that corresponds to the binary filename:
https://github.com/SASlabgroup/microSWIFT_V2.2_Firmware/tags
This scheme will NOT work for the official releases, where filenames are all the same.