Add CascadingNamespaceSettingAttribute step to Settings Module

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Work on this issue
• Close this issue

MR: Pending (WIP branch: caw-rd-add-group-support-to-settings)

Description

Add CascadingNamespaceSettingAttribute step to Settings Module, with max_hours_before_termination_limit as first supported field.

• See Workspaces Settings Configuration Infrastructur... (&14186) for overview and more context
• See Related Issues and MRs section in that epic for related issues and MRs

Acceptance Criteria

• max_hours_before_termination_limit is supported as a setting with a default value.
• Add step for CascadingSettingReader, after CurrentSettingsReader
• Add all necessary support/migrations for adding Cascading Settings attribute for max_hours_before_termination_limit
• Add the setting to the UI, using the existing approach other teams have used for Cascading Settings values.
• Fully exercise new behavior in spec/lib/remote_development/settings/settings_integration_spec.rb

Technical Requirements

Add max_hours_before_termination_limit as CascadingSetting

• To drive the initial implementation of CascadingSetting behavior, the first setting we will add is max_hours_before_termination_limit.
• This is also a good first choice because it will allow gitlab.com enterprise group admins to override this on a per-group basis, and allow for longer-lived workspaces than the current hardcoded 120 hour max.
• This will involve adding a new CascadingSettings step to the Workspaces ROP Settings Module chain
• This may or may not be dependent upon the Category:Web IDE implementation of the ROP Settings Module. If the implementation is straightforward, they can be done concurrently.
• This will NOT include adding any support for a Project-level setting for max_hours_before_termination_limit (either via extending CascadingProjectSettingAttribute or manually implementing a separate Project step in the ROP chain. That will be done in a future issue once we determine how to approach it.
  • NOTE: However, adding project level settings to CascadingSettings will force us to put project-level settings at a higher precedence level than agent-level settings. If we decide that project-level should be at a lower precedence level than agent-level, we would need to have a separate, dedicated, non-CascadingSettings step in the Settings Module ROP chain BELOW the agent level.
• The instance-level settings UI will be added to the Admin General settings at app/views/admin/application_settings/general.html.haml, similar to the duo_features_enabled setting via = render_if_exists 'admin/application_settings/ai_powered'
• The Group-level UI will be added to the same group-level workspaces setting location which was introduced in Display mapped agents in Workspaces settings (!152216 - merged)
• This will likely be 5+ issues/MRs:
  • one to add a feature flag workspaces_cascading_settings, at the root-namespace actor level
  • one to add just the migrations and backend logic (no need to be behind the feature flag, as no UI is exposed yet)
  • one to add the setting to the group settings UI (behind the feature flag)
  • one to add the setting to the admin settings UI (behind the feature flag)
  • one to default-enable and delete the feature flag

Design Requirements

1. Add new Cascading Settings fields to Workspaces Settings at instance level
2. Add new Cascading Settings fields to Workspaces Settings at group level