Refactor environment scope to use constants
What does this MR do and why?
Refactor environment scope to use constants
The environment scope is re-used in a few places and can be extracted to a re-usable constant, as well as a constant mapping the scope to the correct property name for the count. This is a bit safer than trying to build a property name, especially if more scopes are introduced in the future.
Fall back to avaiable scope if scope is invalid
On environments, only 2 scopes are valid: available and stopped. If an invalid scope is passed via the query params, the controller attempted to use it and would return a 500 error.
This behaviour is still useful for the JSON API, and so we only fetch the environments if the format is JSON.
However, as the environments are fetched via API after the HTML is returned, there's no need to query the environments when the format is HTML, meaning no need to use the scope. This stops invalid query params (like ?scope=foo) from returning a 500 error. To stop the resultant API calls from failing, we can check to see if the requested scope is valid. If it is not, default to the available scope.
Changelog: fixed
Screenshots or screen recordings
NO VISUAL CHANGE
How to set up and validate locally
- Navigate to Deployments > Environments
- Make some environments
- Stop a few of the environments
- Attempt to change the URL to a bad scope, like
foo
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
For #355540 (closed)