Historical build chart is incomplete. Name of default branch is wrong.
novemberkilo opened this issue · comments
Context
The historical build chart should include the latest build but does not. This can cause confusion. Also, the default branch name is wrong.
Current behaviour (examples provided)
This shows a green tick icon to say that the latest build has passed. This is corroborated by the build page. Note also that the default branch is incorrectly master
The build history for main shows
Expected behaviour
The build chart is meant to provide an overview of the recent builds of the default branch of a repo. It should include the latest build. The default branch should also be correct.
Reported by @tmcgilchrist
It looks like for some repos, the history includes the latest commit, and for some it does not.
This can be seen by visiting https://ci.ocamllabs.io/github/ocurrent and hovering over the last column of the charts. For example, ocaml-ci shows the latest ref as also being the last ref of its chart, but mirage-ci does not. This is consistent with the history page of the default branch of the repo.
Any ideas about what's going on here @maiste @benmandrew?
If you look at the OCaml-CI histories for the main and live branches you see that they have disjoint sets of commits, yet according to GitHub (main, live) they should be merged together. This is because within OCaml-CI each commit has a single gref, retrieved using Commit_id.gref from the OCurrent Git plugin.
I think this functionality is meant more as just one given way to retrieve the commit, rather than being a complete set of grefs that the commit belongs to (I should also have recognised that only one gref was being retrieved!).
It would be nice to add the required functionality to the Git plugin if it is possible. It seems like this solution would be the most natural.
Thanks @benmandrew - that was useful information but after chasing it around, I think the issue here is a bit different. The build history comes from the ci_build_summary table of the database and so I spent some time simulating the scenario above (same commit on multiple grefs) to see if I could determine if the information was not being written correctly, or not being read correctly.
My conclusion at this point is that the information is being persisted. The same commit appears against multiple grefs. However, the query being used to read history is not picking up the commit on all the grefs.
I'm making progress and expect to have a fix soon. cc/ @maiste and @tmcgilchrist for information.