Most of the history of gnome-build-meta fails to build
Description
Every GNOME element uses the git_tag
source type and tracking its respective master branch. Because of this, checking out any commit in the past would most likely fail to build as users are force to track every element in the pipeline. In fact, I've personally had a case where checking out the latest commit of gnome-build-meta
also failed to build, even though it passed in CI. It also makes most of gnome-build-meta
's history non-reproducible.
While gnome-build-meta
's git history contains all the changes done in the different element files, the git references for every element are absent from its history.
Instead, the user is expected to track to the tip of every master branch of every element in their pipeline after checkout, regardless of the commit in history that was checked out. The only exceptions are commits that happen to be tagged as a release commit where the tar
source is used instead of git_tag
.
After tracking and building, the reasons for failure are usually additional dependencies that are missing, new build options that need to be set or build issues that are introduced in the code.
While a project.refs
file is generated by CI and saved as a CI artifact, this file is only kept temporarily and one must know about it to use it. This fact makes working with gnome-build-meta
for development quite inconvenient.
In fact, I only recently found out about the project.refs
file that is kept temporarily as a CI artifact. Before this, I had to cross my fingers that a fetch to the tip of everything would build and run fine. The results were usually mixed. I could spend a few hours pulling everything just to realize that some core element doesn't even build successfully. Then I'd have to try to find a commit where that element did build successfully, or figure out which new dependency it's missing, or maybe some build option should be changed, etc.
Possible Solution
If the project.refs
file was also committed to the repository, every (interesting) point in history could be reproduced.
The exact logic of when to commit an update to project.refs
can be discussed, and depends on what we'd want to preserve. A few options are:
- After a successful CI build on the master branch.
- After any CI build on the master branch, including failures. I'm not sure how useful it would be to preserve these points in history as well.
- After a MR is merged, with the
project.refs
it had in its CI. This is a little more complicated scheme, but it could also prevent most of the build failures from reaching the master branch. It would likely also require a merge bot to both avoid moving references back in time, as well as making the commit itself.
Personally, I think option (1) should be sufficient.