By default, adding a label to a resource will trigger its reconciliation. While this is a nice work around, it isn't a great experience to be adding and removing labels when you want to reconcile objects. That is why we added a specialty label on both Promises and resources requested of a Promise which Kratix will remove once the reconciliation has been triggered. Thereby enabling an ever green label you can add and not have to remember to remove. Documentation of this features is here for resources and here for Promises.
This issue is to add the same behaviour for other resources within Kratix's control, namely the Works, WorkPlacements, and Destinations.
The reason this came up is that a user had their state store removed and wanted to repopulate it, but running a workflow did not re-write to the statestore as it did not trigger a diff in the WorkPlacement which is what determines if a write is necessary. While we could just add this behaviour for WorkPlacements, I think it is best we add to the whole stack as there is likely a case we will need for each and best to preempt that.
By default, adding a label to a resource will trigger its reconciliation. While this is a nice work around, it isn't a great experience to be adding and removing labels when you want to reconcile objects. That is why we added a specialty label on both Promises and resources requested of a Promise which Kratix will remove once the reconciliation has been triggered. Thereby enabling an ever green label you can add and not have to remember to remove. Documentation of this features is here for resources and here for Promises.
This issue is to add the same behaviour for other resources within Kratix's control, namely the Works, WorkPlacements, and Destinations.
The reason this came up is that a user had their state store removed and wanted to repopulate it, but running a workflow did not re-write to the statestore as it did not trigger a diff in the WorkPlacement which is what determines if a write is necessary. While we could just add this behaviour for WorkPlacements, I think it is best we add to the whole stack as there is likely a case we will need for each and best to preempt that.