Highlight paid features during active trial - Part 1

What does this MR do?

Sets the groundwork for the “Highlight paid features during active trial” experiment. Mainly, it sets up a new experiment using the gitlab-experiment gem (GLEX) and creates the initial badge component that will be used as the building block for the rest of the experiment features.

Screenshots

Before	After

How to test this locally

1. To test locally, you’ll need to hop into the ee/app/helpers/paid_feature_callout_helper.rb file and change line 5 like so:

   -    experiment(:highlight_paid_features_during_active_trial, group: group) do |e|
   +    experiment(:highlight_paid_features_during_active_trial, :candidate, group: group) do |e|

   This forces the experiment to present the :candidate experience every time it runs.

2. You’ll also need to enable billing plans & trials in your local dev application instance. You can do this from the Rails console:

   ApplicationSetting.first.update(check_namespace_plan: true)

3. Then you need a group that is in an active trial. It’s easy enough to set this up from the Rails console:

   group = Group.find(112) # use the ID of whatever group you want to test with; make sure it is a top-level group, though
   plan = Plan.find_by(name: 'ultimate') # if this returns nil, you will need to create the "Ultimate" plan
   subscription = group.gitlab_subscription || GitlabSubscription.new(namespace: group)
   subscription.hosted_plan = plan
   subscription.trial_starts_on = Date.current
   subscription.trial_ends_on = Date.current.advance(days: 30)
   subscription.trial = true
   subscription.save
   # then you should see...
   group.reload.trial_active? # => true

   Make sure you use a group which you are an owner or maintainer of, otherwise you’ll need to add your user as an owner or maintainer member of that group.

4. Then you need a project in that group. This is quite easy to do from the UI.

5. Then you’ll need to initiate a repository for that project. You can do so by choosing one of the “Create README” type options at the top of the project overview page and putting in some simple README content.

6. Then you’ll need to initiate a Merge Request for that project. You can edit the newly created README file in the web IDE and have it automatically create a new branch and MR for you. This will take you to the MR creation page which is where you’ll see the paid feature callout badge.

7. You can also save that MR and then edit it to see the badge on the edit page for the merge request.

Related MRs

MR	Description
!56155 (merged)	👈 You are here
!58834 (merged)	Adds the feature flag so that we can at least enable the experiment, thus far, in Staging
!58827 (merged)	Adds the popover with more information but no CTAs

Does this MR meet the acceptance criteria?

Conformity

• 📋 Does this MR need a changelog?
  • I have included a changelog entry.
  • I have not included a changelog entry because this experiment is behind a feature flag.
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team

Related to #273626 (closed)