CLI BUG: `pydarm ls -r` fails to list all exported tags if more recent commits exist in report repo
The CLI tool to list reports and their tags, pydarm ls -r
, in the control room fails to recognize export tags when there are more recent commits in the report repository.
This was found to be an issue at LHO (and contributed to more lost time that I'd care to admit).
Here are the last few lines returned by running pydarm ls -r
in the LHO control room:
20240914T183802Z
20240917T222803Z exported-20240917T224755Z exported-20240925T042033Z valid
20240918T040838Z
20240919T153719Z
20240925T043205Z exported-20240925T043534Z valid
louis.dartez@cdsws22:
The output properly lists all the reports in /ligo/groups/cal/H1/reports/
and purports to list all of their relevant tags. It turns out that the output is wrong; we happen to know that 20240919T153719Z has been exported at least once. So where are its tags?
N.B. 20240917T222803Z and 20240925T043205Z are 'fake' reports that, other than their id's, are carbon copies of other reports. However, I don't believe that this fact has any bearing on the bug I'm reporting here.
As evidence that 20240919T153719Z has been exported I offer an excerpt of the output produced by running git log
from within the report directory (/ligo/groups/cal/H1/reports/20240919T153719Z/
):
The same screenshot shows the last commit tagged as an export is two commits behind the tree head. Most likely, pydarm ls
is just looking at the top level commit when searching for tags instead of cycling through the history. In that way, this Issue is related to #266.
As a confirmation that this is what's happening I can checkout an exported commit and inspect the output of pydarm ls -r
.
Running
git checkout d562eb
pydarm ls -r
produces the following:
20240914T183802Z
20240917T222803Z exported-20240917T224755Z exported-20240925T042033Z valid
20240918T040838Z
20240919T153719Z exported-20240925T032920Z valid
20240925T043205Z exported-20240925T043534Z valid
louis.dartez@cdsws22:
This shows that an export tag is only shown when the HEAD is tagged. This can have the unintended effect of missing exported commits when looking back down the line to try and reconstruct things.