<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=468797) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=468797) </details> <!--IssueSummary end--> MR: Pending (WIP branch: [caw-rd-add-group-support-to-settings](https://gitlab.com/gitlab-org/gitlab/-/tree/caw-rd-add-group-support-to-settings?ref_type=heads)) ## Description Add CascadingNamespaceSettingAttribute step to Settings Module, with `max_hours_before_termination_limit` as first supported field. - See https://gitlab.com/groups/gitlab-org/-/epics/14186+ for overview and more context - See [Related Issues and MRs section in that epic](https://gitlab.com/groups/gitlab-org/-/epics/14186#related-issues-and-mrs) 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 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/152216+ * 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 1. Add new Cascading Settings fields to Workspaces Settings at group level <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->