As time progresses there is a risk that the recert code that IBU depends on to inject data into IBU upgraded clusters will become out of sync with OCP as OCP component teams refactor their code, add & remove certs, etc.. In order to mitigate this risk, we will create a CI job which will run a dry-run of recert in order to determine which resources will be touched by recert, and compare the list of resources to the tls-artifacts registry.

It's entirely possible that the cluster will "pass" the ordinary set of blocking CI jobs and when a mismatch occurs (e.g. if the resource in question is utilized in error handling, or only used a production environment), the job will fail, informing component teams that recert (lifecycle agent) needs to be updated.

Recert modifies more resources than are currently being tracked in the tls-artifacts registry (e.g. JWT tokens, and resources containing a hostname string) - for this reason, we will initially fail when there is something in the registry that isn't in the list of resources specified in the dry-run, or if the dry-run resource list (filtered by the types that re in the tls-registry) contains resources that are not in the registry.