CLDSRV-397 Introduce the time-progression-factor flag #5192
Conversation
Hello nicolas2bert,My role is to assist you with the merge of this Status report is not available. |
Incorrect fix versionThe
Considering where you are trying to merge, I ignored possible hotfix versions and I expected to find:
Please check the |
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
|
tests/unit/Config.js
Outdated
| describe('time options', () => { | ||
| afterEach(() => { | ||
| // Clean up the environment variables | ||
| delete process.env.EXPIRE_ONE_DAY_EARLIER; |
There was a problem hiding this comment.
delete may reset an otherwise useful (for later tests) env variable...
the better way to set env variables in test is to use setEnv(), which will store the earlier value and automatically restore or reset at the end of the test.
There was a problem hiding this comment.
Yes, agree, I updated the PR.
| @@ -19,8 +20,9 @@ function calculateRetainUntilDate(retention) { | |||
| const date = moment(); | |||
| // Calculate the number of days to retain the lock on the object | |||
| const retainUntilDays = days || years * 365; | |||
There was a problem hiding this comment.
unrelated to this PR, but i wonder if the semantics of 'years' parameter here is correct with respect to leap years...
nicolas2bert
force-pushed
the
improvement/CLDSRV-397/timeProgressionFactor
branch
3 times, most recently
from
74d6031 to
4aa98c4
Compare
The "time-progression-factor" variable serves as a testing-specific feature that accelerates the progression of time within a system. By reducing the significance of each day, it enables the swift execution of specific actions, such as expiration, transition, and object locking, which are typically associated with longer timeframes. This capability allows for efficient testing and evaluation of outcomes, optimizing the observation of processes that would normally take days or even years. It's important to note that this variable is intended exclusively for testing purposes and is not employed in live production environments, where real-time progression is crucial for accurate results.
nicolas2bert
force-pushed
the
improvement/CLDSRV-397/timeProgressionFactor
branch
from
7979cf1 to
c8150c6
Compare
|
@bert-e approve |
In the queueThe changeset has received all authorizations and has been added to the The changeset will be merged in:
The following branches will NOT be impacted:
There is no action required on your side. You will be notified here once IMPORTANT Please do not attempt to modify this pull request.
If you need this pull request to be removed from the queue, please contact a The following options are set: approve |
|
I have successfully merged the changeset of this pull request
The following branches have NOT changed:
Please check the status of the associated issue CLDSRV-397. Goodbye nicolas2bert. |
The "time-progression-factor" variable serves as a testing-specific feature that accelerates the progression of time within a system.
By reducing the significance of each day, it enables the swift execution of specific actions, such as expiration, transition, and object locking, which are typically associated with longer timeframes.
This capability allows for efficient testing and evaluation of outcomes, optimizing the observation of processes that would normally take days or even years.
It's important to note that this variable is intended exclusively for testing purposes and is not employed in live production environments, where real-time progression is crucial for accurate results.