fix(lifecycle-operator): introduce separate controller for removing scheduling gates from pods

[bacherfl]

Closes #2937

This PR introduces a dedicated controller that takes care of removing the scheduling gates of a pod for which there is a related KeptnWorkloadVersion that has passed the pre deployment phase.

This might be the more robust solution, as opposed to the one proposed in the issue description, as checking for completed KeptnWorkloadVersions for a pod in the mutating webhook might lead to some timing issues (e.g. when a KeptnWorkload is finished during the timeframe between adding the scheduling gate in the webhook and the completion of the webhook where the scheduling gate is actually applied).

Note that for pods where the checks of the related KeptnWorkloadVersion have already passed, the controller will just remove the scheduling gate from the pods - pre/post deployment tasks which have already been executed for the WorkloadVersion will not be executed again

[codecov]

Codecov Report

Attention: 24 lines in your changes are missing coverage. Please review.

Comparison is base (882b442) 52.85% compared to head (cea1a33) 85.77%.
Report is 20 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #2946       +/-   ##
===========================================
+ Coverage   52.85%   85.77%   +32.92%     
===========================================
  Files          22      162      +140     
  Lines        1771    10351     +8580     
===========================================
+ Hits          936     8879     +7943     
- Misses        740     1184      +444     
- Partials       95      288      +193     

Files	Coverage Δ
...cle-operator/controllers/common/helperfunctions.go	98.41% <100.00%> (ø)
.../controllers/lifecycle/keptnworkload/controller.go	82.41% <ø> (+18.68%)	⬆️
...llers/lifecycle/keptnworkloadversion/controller.go	90.31% <66.66%> (+26.35%)	⬆️
...ontrollers/lifecycle/schedulinggates/controller.go	67.18% <67.18%> (ø)

... and 147 files with indirect coverage changes

Flag	Coverage Δ
certificate-operator	67.42% <ø> (?)
component-tests	56.73% <66.66%> (+0.93%)	⬆️
lifecycle-operator	85.28% <63.85%> (?)
metrics-operator	87.63% <ø> (?)
scheduler	36.53% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[RealAnna]

would it make sense to recreate the issue with a kuttl/chainsaw test?

having a deployment annotated for keptn with a simple pre task. After it passes delete the pod and check 1- it gets gated 2- the gate is removed?

[odubajDT]

left small comment, but leaving it up to you :)

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud