We should delete unnecessary environments in order to speed up git operation. This brings a lot of benefits to entire GtiLab features, especially GitLab-Runners that the total amount of refs they need to fetch will be significantly reduced.
Proposal
Delete stopped environments automatically.
Which environments will be deleted?
The environment has already been stopped for more than a month.
If the review/something environment is running for a week, it'll be stopped by environment auto-stop feature feature.
If the review/something environment has been stopped for a month, it'll be deleted by the new feature.
The production environment will never be stopped automatically.
If the production environment has been stopped by manual operation, it won't be deleted because the environment was not stopped by environment auto-stop feature feature.
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
@dosuken123 is it worth having a sane default like 1 week that doesn't need to be set, and can be st to never if needed? Maybe this would need to be a follow up issue.
@dimitrieh I don't think so. This is more like one of the background housekeeping processes, like artifact expiration, container image expiration, etc.
It might be better to leave Audit Event like <Deleted count> environments in this project were deleted for optimizing the repository. This is possible, but there is a performance implication so maybe a follow-up.
To view a project’s audit events, navigate to Project > Settings > Audit Events. From there, you can see the following actions:
why there is a performance implication of doing so?
Our cron worker likely cleanup environments at instance-level, and not project-level as it's the most performant approach in database perspective. Calculating the number of deleted environments per project is something extra process on the process. We need a technical investigation if we can achieve that with the same optimization level of instance-level process.
I agree with @dosuken123. It is a background job and there is no need to inform the user about it (to initiate this - there must be a stopped environment which resulted from user action) I opened an issue for logging #237853
@shinya.maeda Is it worth notifying users of this change of behavior on the environments page? Either with a general alert on the page, or an alert on the environment itself?
I plan to have a design proposal for it early next week, let me know if that timeline works considering this is ~"Release::P1" for the current milestone.
@nicolewilliams@shinya.maeda Apologies for the long response time on this! Having a hard time managing capacity this milestone
Added a proposal for the alert on the description. I tried finding a balance in the copy between informing users so they don't think their important environments will be removed, but without giving too much details and overcomplicating it.
@rdickenson Would be great to know your thoughts on this copy I assume documentation should also be updated for this feature.
@dfosco Thank you for providing a screenshot. It looks awesome!
Sorry that there was a miscomunication that we're currently focusing on #336926 (closed) instead of this issue (There was an priority change). The reason is because #336926 (closed) addresses the whole root cause, whereas this issue addresses the problem partially. By the reason, any UX works in this issue can be held off for now.