Skip to content

Fix deploy freeze when it overlaps with itself

Vladimir Shushlin requested to merge 370472-deploy-freeze-time-period-logic-does-not-apply-congruently-with-cron-schedules into master

What does this MR do and why?

Fix deploy freeze when it overlaps with itself, see Deploy freeze time period logic does not apply ... (#370472 - closed)

☝ this is much easier to review in the side-by-side view 😉

The old logic was quite hard to understand:

This code tried to calculate 4 points in time

  1. last time freeze is started
  2. last time freeze is ended
  3. next time freeze is starting
  4. next time freeze is ending

And then tried to make sure that:

  1. Time.now is within [last time freeze is started .. next time freeze is ending]
  2. Last freeze is not yet ended last time the freeze is ended < last time the freeze is started
  3. That the next freeze end belongs to the current freeze, not the next one: next time freeze is starting > next time freeze is ending.

The problem was in the last condition. If period overlaps with itself: e.g. starts on every minute in Aug, and ends on every minute in Oct(that basically means that there are a lot of freezes starting each minute of Aug, and all ending on the first minute in Oct), then the last condition will be false for any minute in Aug. That happens because there is deploy freeze starting on the next minute, so this condition thinks that the next deploy freeze end belongs to this future deploy freeze.

The new logic is quite straightforward:

  1. calculate the last time when freeze is supposed to be started
  2. calculate when it's supposed to be ended
  3. check if Time.now is within this range

It satisfies all the previous test examples and fixes the bug with overlapping deploy freeze.

How to set up and validate locally

I was just running tests, since it's basically a boolean function. But here's the documentation, if you want to setup in the UI: https://docs.gitlab.com/ee/user/project/releases/index.html#prevent-unintentional-releases-by-setting-a-deploy-freeze

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Vladimir Shushlin

Merge request reports