-
Notifications
You must be signed in to change notification settings - Fork 14
Keep ref change history in GitTracks #175
Description
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:
apiVersion: faros.pusher.com/v1alpha1
kind: GitTrack
[...]
status:
conditions:
[...]
history:
- changeTimestamp: "1970-01-01T00:00:00Z"
before:
Repo: "[email protected]:me/software"
Ref: "someTag"
Sha: "d670460b4b4aece5915caf5c68d12f560a9fe3e4"
after:
Repo: "[email protected]:me/software"
Ref: "someTag"
Sha: "a945bc1f1b1be9cca6af5c6a713f500b64ff43"
- changeTimestamp: "1970-01-01T01:00:00Z"
before:
Repo: "[email protected]:me/software"
Ref: "someTag"
Sha: "a945bc1f1b1be9cca6af5c6a713f500b64ff43"
after:
Repo: "[email protected]:me/software"
Ref: "someOtherTagOrBranch"
Sha: "5e893d595c731cd8523b254cc6a2597228cea0f6"
[...]
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?