Skip to content

Registration Features - Group-level Wiki

Overview

As part of our registration features initiative we'd like to move Group-level Wiki down to the "Registration Feature" tier.

Timeline

We're working to get the SOW locked down the week of 2023-08-21 or the following week. Once that's done we'll need to get SoftServe onboarded (estimating ~1-2 weeks following as the earliest start, but can't say definitively yet). The goal would be to get these moves landed by end of the fiscal quarter (2023-10-31) which aligns with %16.5 or %16.6 as the release depending on when it can land.

Expectations on GitLab team members

Please help SoftServe with any questions they may have, code reviews, approvals, and merges. Thanks!

Success Criteria

  1. When the registration features sub-setting is On, the feature set is provisioned in the instance
  2. When Service Ping is Off => No change to Off behavior since release of &6144 (closed)
    1. The sub-setting is set to Off
    2. The sub-setting is disabled for selection
    3. The instance no longer receives the paid feature set
  3. This change should not change the instrumentation of this feature
  4. Updates docs: Add the feature to the list in this section and link to the docs for it. The regular documentation for the feature will still reflect that is it 'Premium'

Instructions

Note: Note - these instructions have been updated based on Update instructions on how to move paid feature... (#423232 - closed).

See the following MR for reference on adding features to the Registration Features program:

  1. Implementation:

    • Move the feature symbol in GitlabSubscriptions::Features from its corresponding tier in the <TIER>_FEATURES constant to <TIER>_FEATURES_WITH_USAGE_PING. If the feature is global, then don't remove it from the GLOBAL_FEATURES constant.
    • Test the feature manually using the following validation steps. If the feature isn't disabled/enabled properly, it might be coupled with the rest of the codebase in an unusual way. See !118760 (diffs) for an example, where a GitLab Geo feature relies on additional conditional checks. Ask the group owning the feature if you're not sure about the details.
      • Add specs if you add new logic
    • Add the feature to the Registration Features docs

  2. Validation steps:

    1. Testing previous behavior:
      • Make sure you're on a Premium/Ultimate plan GitLab GDK instance
      • Try to use the feature - it should be enabled and working
      • Include the steps to use the feature for the reviewer below:
        • Step 1.
        • ...
    2. When registration features are enabled:
      • Make sure you're on a free plan GitLab GDK instance (for example, remove current license or stub #current to return nil)
      • Make sure you have the registration features checkbox enabled (Admin -> Settings -> Metrics and profiling -> Usage statistics -> Enable Registration Features)
      • Try to use the feature - it should be enabled and working
      • Include the steps to use the feature for the reviewer below:
        • Step 1.
        • ...
    3. When registration features are disabled:
      • Make sure you're on a free plan GitLab GDK instance
      • Make sure you have the registration features checkbox disabled (Admin -> Settings -> Metrics and profiling -> Usage statistics -> Enable Registration Features)
      • Try to use the feature - it should be disabled and not usable
      • Include the steps to use the feature for the reviewer below:
        • Step 1.
        • ...
    4. Make sure that the new text appears on the docs page:
      • run gdk restart gitlab-docs
      • go to <local_gitlab_docs_host>/ee/user/admin_area/settings/usage_statistics.html#registration-features-program and make sure the new section is on the page and the link works
Edited by Ian Pedowitz