Audit trail to manage configuration drift of Installerset managed resources

Feature Request

Add support for retaining an audit record of changes made to resources managed by TektonInstallerSet.

Use Case

We frequently encounter situations where a user sets component configuration through the TektonConfig, but later manually updates the generated ConfigMap to a different value. Because this change is made directly to the resource not through TektonConfig, the TektonInstallerSet does not reconcile it (as there is no corresponding change in the TektonConfig).

During a subsequent upgrade, the installer set overwrites the manually modified values in the ConfigMap, restoring the defaults defined by the operator. Users then report issues because their custom configuration appears to have been “lost” after the upgrade.

This leads to significant troubleshooting overhead, as it is difficult to determine:

• what the configuration previously was,
• who changed it, and
• whether it was modified manually outside of the operator workflow.

To address this, can we come up with solution that can retain or expose an audit trail of changes to resources managed by TektonInstallerSet, so that unexpected configuration overwrites can be diagnosed more easily.

cc: @aThorp96 @ab-ghosh

Start by tracing how TektonConfig and TektonInstallerSet produce and update the generated ConfigMap. Define what the audit record must retain, including prior configuration, the actor, and whether a change occurred outside TektonConfig. Done should mean an agreed, implementable audit-trail design with its behavior for upgrades and manual changes.