[Feature Request] Improve reproducibility and traceability of builds

[beroset]

Improve reproducibility and traceability of builds An issue that came up recently in conversation with @MagneFire was that currently, it's hard to track changes making it hard to find issues whenever they appear.

A build for a particular watch on a particular date is spread over eight different top-level repositories:

• asteroid
• meta-asteroid
• meta-asteroid-community
• meta-openembedded
• meta-qt5
• meta-smartphone
• meta-smartwatch
• oe-core

Most of those, in turn, pull in multiple different subrepositories. So if a change somewhere has caused a problem, it's not always very obvious how to go about finding which change is responsible. An example is this: https://github.com/AsteroidOS/asteroid/issues/94

Potential solutions

1. Don't use AUTOREV instead use fixed commits and update them manually or automatically.
2. Use labeled branches to quickly test older versions (ex. After Yocto base changes, changes affecting many components)

Describe the feature you'd like As mentioned in https://docs.yoctoproject.org/test-manual/reproducible-builds.html the goal is to make sure that

a given input build configuration will give the same binary output regardless of when it is built (now or in 5 years time), regardless of the path on the filesystem the build is run in, and regardless of the distro and tools on the underlying host system the build is running on.

If, for example, we know that a build of a particular watch worked at one point and failed at some later date (e.g. like this: https://github.com/AsteroidOS/asteroid/issues/260 ) it would be very useful to quickly figure out which change induced the problem.

Additional context Having reproducible builds is a useful step toward having CI/CD testing of changes and may also help with issues like this: https://github.com/AsteroidOS/asteroid/issues/224

[FlorentRevest]

Don't use AUTOREV instead use fixed commits and update them manually or automatically.

Imho it mostly boils down to this automation. I agree that AUTOREV isn't great for the reasons detailed here but until we automate it, it's just gonna be a massive pain in the back to tell every contributor "please also bump the SRCREV in the yocto layer" so I'd prioritize automating it.

Doesn't dev-tool already have a way to bump the commit of a recipe ?

Maybe we could keep a list of recipes which we want to autobump and automatically call that dev-tool feature as a first step of our autobuild script or so.