Validate release date on continuous queues manager

[junpataleta]

This fixes #293

[stronk7]

Thanks @junpataleta , and covered with tests, yay!

It looks perfect, will merge as soon as all checks are done, hopefully green.

Ciao :-)

[stronk7]

As commented via chat, I think that we have to remove the 2 "dry-run" tests. We cannot test that because they require the tracker to be available (for querying). And it's not, so they are failing, and bats is warning us about that (because they don't have any assert_success or assert_failure.

So, the 2 solutions are:

1. or we remove the dry-run tests.
2. or we add assert_failure to them, because they are going to fail yes-or-yes (I imagine).

Personally, I'd remove them, because we are not going to be able to test the script without a real tracker, so no query or update can be tried ever.

Ciao :-)

[junpataleta]

Thanks, @stronk7. I went with the approach of moving the parameter validation to its own function so it can be tested separately. I tidied up the patch. Please have another look.

[stronk7]

We are 99% there, great refactor and tests! I've added a couple of comments in the patch...

[junpataleta]

Thanks for your patience to a bash/bats naab like me, @stronk7 😅. I have made the changes you mentioned.

I also added validation to ensure that lastweekdate is not after the releasedate.

I hope this is good to go.

[stronk7]

Thanks, @junpataleta both for the PR and your patience! Hope it has been a good experience, heh!

About to merge this now, yay!

PS: We still have to discuss if we want, before enabling this script, to have a job to do both:

• Move IR issues from candidates to current (right now done by the TR- Move awaiting... and documented).
• Avoid CLR issues, that don't have the candidates/current split to be held (this time we have done it adding the unheld standard comment). There isn't a job for this, neither it's documented.

Notes:

• It can be a new job only for the CLR issues, or we can join both actions together.
• If the "adding the unheld standard comment" is not elegant solution, we can always create some field or add a more specific comment (sort of "This issue made the freeze while sitting in the CLR queues" or so). Then we can edit the filters to also avoid issues with that other comment.

Just using this PR to have my thoughts shared, heh.

Ciao :-)

[junpataleta]

Yay! Thanks, @stronk7!

I think that the the continuous queues manager should be handling this task of holding or keeping waiting for CLR issues.

About preventing CLR issues from being held, would it be possible to get the date when the waiting for CLR issue has been sent to integration? For example, fetch the date when the issue's status changed from Peer review in progress to Waiting for integration.

Then if it's determined that the date/time the issue was sent to integration falls before the code freeze, it will not be held. Otherwise, it will be held by the continuous queues manager.

What do you think?

[stronk7]

After a chat with Jun, we have agreed about:

• Right now, the continuous queue manager already manages the CLR queue ok (in fact it held a lot of new features/improvements, heh).
• The critical point is, exclusively, before enabling the continuous queues manager, about how to instruct it that a CLR issue did the freeze (or no), in order to ignore issues that did it.
• For comparison, with IR issues, we have the "Current in integration" field, that is that we use to differentiate which issues can be held. But we don't have that for CLR issues.
• So we have to "invent" or "use" something, to be executed before enabling the manager in order to ensure that it's able to detect which CLR issues have made the freeze (to avoid holding them).
• For 4.4 freeze we have added the official "unheld" message to work-around the problem (the manager skips any issue with that comment), but that's not correct, because those issues shouldn't have been held.

Current proposals are about to:

• Add a new condition, date based, to select CLR issues. It could be something (untested) like:

AND status WAS NOT ("Waiting for CLR") BEFORE "<<freeze_exact_date_and_time>>"

• Add a new, more accurate, official comment like "This CLR issue did the freeze and must be considered....". And then make the queues manager to ignore any issue having that comment.

So, next:

• I will explore the 2 current proposals. For some reason I find the 1st one harder to implement (and easier to forget to configure correctly).
• Will create a new job, call it "TR - Before enabling the continuous manager" that will do BOTH: What the current "Move issues to current" job does for IR issues AND whatever we plan as solution for the CLR issues.
• Amend the docs to ensure that the new job is executed before enabling the continuous queues manager.

Ciao :-)