Provide a mechanism to clean up stale environments
Release notes
An API was added to help with cleaning up stale environments. The API will issue a stop request to all environments that were last modified or deployed to before a specified date. This feature excludes protected environments.
Problems
Problem 1: Available-but-Empty environments are useless
Each GitLab Environment has one of the two states - available or stopped. When an environment is created, it has the available state, because there should be a deployment job run soon.
However, in some Review App usecases, a user doesn't deploy to the created environment at all. For example, a user could manually deploy to a review app in an MR, but the user didn't do it. In this case, the environment stays as available state, but it'll never get a deployment record, which means useless in environment management.
In fact, we can see this problem in www-gitlab-org project, that we have the review-docs manual job which created review-docs environments. As you can see, we currently have almost 500 environments, 95% of which do not have a deployment.
Problem 2: There is no one-click button to stop Available-but-Stale environments at once
We expect users to properly configure the automation for stopping environments, however, sometimes users don't see it fits in their organizational practice or simply forgot to configure it. In this case, they don't have a way to cleanup old multiple environments at once. Instead, they have to either:
- Click "Stop" button for each individual environment https://docs.gitlab.com/ee/ci/environments/#stop-an-environment. This takes time and cumbersome.
- Write bash script to call Stop Environment API for each individual environment. This requires a technical knowledge and becomes a burden for users that they have to maintain the script.
Proposal
We add a one-click button in Environments Index page to stop these environments at once.
- When a user clicks the button, it shows a modal.
- Users select a specific date. Environment's
updated_at
older than the specific date will be targeted.- Max: 10 years ago Min: 1 week ago
- Default: 1 year ago
- Button: Clean up or Cancel
- Note: Protected environments are always excluded from this clean up.
- Note: We should hint users that environments can also be cleaned up in the other methods.
- If users have too many stale environments, they should perform per each year e.g. 10 years ago => 9 years ago. This is safer from user and GitLab perspective.
- Users select a specific date. Environment's
Modal |
---|
Technical Proposal
- Adding a new worker
StopStaleEnvironmentsWorker
to handle finding and stopping stale environments, as the query to find stale environments can be costly - Add a new endpoint to invoke this worker from the UI
stop_stale_environments
- Add a new modal to handle calling the new endpoint as shown in the mockups above
UX Flow
Figma File
Permission
Available for Maintainer+. Not available for Developer-. See GitLab CI/CD permissions for more information.
Potential follow-up
- Preview environments that will be cleaned up.
- Alert that environments are being cleaned up.
- An additional filter: Name filtering (Optional)
- An additional filter: Only associated with merge requests (Optional)
- This action should be recorded into Audit Event.
Use cases
For people struggling to clean up stale environments.
Old UX Proposal
Proposal
Provide a button that will stop and delete all environments that are currently with no deployment, or are older than a specified date. That action would be similar to the "Delete merged branches" https://docs.gitlab.com/ee/user/project/repository/branches/index.html#delete-merged-branches.
We released in 12.4 a separate API update to make this possible from a script https://gitlab.com/gitlab-org/gitlab-ee/issues/5582.
This issue makes this solution complete by making this available from the UI as well. \
Environments page
- Add a button to the header to link to the clean up environments page.
- Clean up environments button is hidden when a cleanup process is in progress.
- When a cleanup process is in progress display an informational alert
- Alert is dismissable but should reappear on page load
- Alert indicates the current progress of the job
- Action button allows a user to cancel the cleanup process
- Once the job has completed, the alert will not be shown on subsequent page loads
Scenario | Mockup |
---|---|
Clean up in progress | |
No deployment clean up in progress | |
Inactive deployment clean up in progress |
Clean up environments page
- Default to No deployment
- Disable date input if No deployments option is selected
- Default date input to 30 days in the past
- Validate date input and disable
Clean up
button if invalid- Date must be a valid date
- Date must be in the past
Scenario | Mockup |
---|---|
Inactive deployments option is selected | |
Date input disabled when other clean up options are selected | |
Date input error |
Feature checklist
Make sure these are completed before closing the issue, with a link to the relevant commit.
-
Feature assurance -
Documentation -
Added to features.yml
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.