In many cases it is desirable to know when a change was applied to a given cluster, e.g. when reviewing incident impact.
Currently GitTracks only contain information on what git repository and reference they are currently tracking. This means that the only way to identify when a chance took effect is to review the git history to find the commit timestamp of the change in question.
This is fine if the reference is a branch and changes are effected by merging commits into that branch.
If instead using tags or where branches get force-pushed frequently, this information is not available from the git history at all.
For this reason it would be good if GitTracks recorded a history of changes themselves.
One way this could be done is by including a list of changes in the status like so:
This would capture both moving tags (as in the first example) as well as changes to the reference used (as in the second example).
For brevity reasons, the list should be limited to a fixed number of entries and the oldest replaced on update. 10 changes might be a reasonable default?
In many cases it is desirable to know when a change was applied to a given cluster, e.g. when reviewing incident impact.
Currently GitTracks only contain information on what git repository and reference they are currently tracking. This means that the only way to identify when a chance took effect is to review the git history to find the commit timestamp of the change in question.
This is fine if the reference is a branch and changes are effected by merging commits into that branch. If instead using tags or where branches get force-pushed frequently, this information is not available from the git history at all.
For this reason it would be good if
GitTracks
recorded a history of changes themselves. One way this could be done is by including a list of changes in thestatus
like so:This would capture both moving tags (as in the first example) as well as changes to the reference used (as in the second example).
For brevity reasons, the list should be limited to a fixed number of entries and the oldest replaced on update. 10 changes might be a reasonable default?