hello-bar
)GitLab's Marketing Site (about.gitlab.com) is led by the Digital Experience Team and anyone can contribute.
The DRI for the Marketing Site is Michael Preuss, and internal GitLab team members can drop questions in Slack at #digital-experience-team
This documentation refers to GitLab Website pages that live in the www-gitlab-com
repository. The Digital Experience team is migrating GitLab's Marketing Site to the Buyer Experience Repository</li>.
Serve the needs and interests of our key audiences:
Generate demand for GitLab by:
The GitLab marketing site, or simply the "GitLab Website" refers to all of the content on https://about.gitlab.com
and the contents of sites/uncategorized
in the www-gitlab-com rexcept for:
docs.gitlab.com
gitlab.com
about.gitlab.com/handbook
See Where should content go? to learn which web property is the most appropriate place to put different types of content. To learn what section of the website different content belongs see definitions.
Known Issue: There is an ongoing issue to further clarify the DRI(s) for various parts of the www-gitlab-com repo and project, and this is a Q2 FY22 OKR for Inbound Marketing
As of 2021-04-27, we are actively auditing the tracking, cookies, and other 3rd party personalization tools installed on the GitLab Website to ensure we are only collecting the information needed to deliver our service.
TBD - format will be a table with a list of tracking tools and brief description of purpose.
For example: Google Analytics web metrics
GitLab also publishes a list of all the technology that GitLab currently uses to support the business.
A topic is an industry trend, theme, or technology related to GitLab and our customers. For example, DevOps, GDPR, Containers, etc. Topic pages on our website educate the reader about the topic and share GitLab’s point of view while providing additional links to resources related to that topic. These pages are intended to attract search traffic.
Topic pages should exist at the root level of the website without being nested inside of another directory. e.g. /continuous-integration
Examples of other companies who have topic pages:
A solution is a combination of products and services that solve a business problem. For example, accelerating software delivery, enabling remote teams, ensuring compliance, etc. Solution pages on our website show the application of GitLab capabilities and services to address a business problem while providing additional links to resources related to that solution.
Solution pages should be nested inside of the solutions directory. e.g. /solutions/continuous-integration
Examples of other companies who have solutions pages:
The product section of our website has pages that describe what GitLab does and the value provided. The functionality of GitLab is ordered in a hierarchy with 4 levels: Stage, Categories, Capabilities, and Features. You can find details on the Product Categories Handbook
Category pages should be nested inside of the product directory. e.g. /product/continuous-integration
Examples of companies who have product/features pages: https://mailchimp.com/features/ https://www.groovehq.com/features
There are two comparison sections on our website, /compare/
and DevOps tools.
The DevOps tools section provides an in-depth, feature by feature comparison of GitLab and our competitors. Pages in the DevOps tools section are maintained by the Competitive Intelligence team, which is part of the Product and Solution Marketing team.
Pages in /compare/
are shorter and focused on a single Call to Action that offers relevant resources to visitors arriving via paid advertising. Pages in /compare/
are maintained by Growth Marketing team and Marketing Program Managers.
Examples of companies who have comparison pages: https://postmarkapp.com/compare/sendgrid-alternative https://www.zendesk.com/support/features/zendesk-vs-intercom/
Similar content can appear as a topic, solution, and in the product section with different emphases on each page. For example continuous integration:
/continuous-integration
would talk about what CI is at a functional level./solutions/continuous-integration
. would talk about why CI is important for businesses to adopt./product/continuous-integration
would talk about the capabilities and features that are part of GitLab's CI functionality and the value it has.If you need support please review the information on the Digital Experience Hanbook Page
Use consistent language across the site when naming links, page names, directory names, page titles, etc. If you see inconsistent language, log an issue to correct. We use american english on the site. Here are some examples below. If in doubt, ask in the #marketing
slack channel for language help.
Do use nouns when appropriate
/product/
/community/
/events/
Do use the imperative tense as much as possible
Don't use noun forms of verbs
Don't use present participle ("ing" words)
Nouns may end in "ing"
Use MVCs to update the website. Create new pages and add the minimal amount of viable content. You can add images and more content in iterative steps.
All pages should use lowercase URLs to help avoid unintentional errors when linking to pages on about.gitlab.com.
We have 10-20 seconds to tell visitors why they should stay on our pages. Tell visitors what value the page will give them. Start with a high-level summary opening the page. This could be as simple as a single sentence, but we shouldn’t put the burden of discovering the value of the page on visitors.
The page title and URL should include keywords visitors might use to discover the page you’re creating. If you’re not sure what terms a visitor might use, ask the Growth Marketing team for suggestions in your Merge Request. We have a list of high priority topics and recommended keywords to use.
Below, view a video that shows a typical workflow to update the website.
In the GitLab Unfiltered video below, Sarah D., marketing operations manager at GitLab, shows Wil S., social marketing manager at GitLab, how to add a new page to your section of the handbook complete with a new main page and table of contents.
If you are an engineer, be sure to check out our developer docs.
If adding a new top level directory to the marketing site, make sure to add to data/monorepo.yml
under uncategorized/paths
.
Docs on monorepo.
To create a new page you for follow these steps:
Draft:
.sites
folder. This is where webpages are stored.uncategorized
directory. If these is an update to the handbook, select the handbook
directory. Once you have selected the site where you would like to make the change, choose the directory where you want your webpage to be. For example, if you put a page in the uncategorized
folder it will show up at the "root" level, if you create the new directory inside of another directory it will appear at that path.New directory
from the plus sign drop down.solutions
directory and inside the solutions
directory create a new directory called cloud-native
.New file
from the plus sign drop downindex.html.md.erb
---
layout: markdown_page
title: ""
---
## Subheading
Here is your first paragraph replace this text.
index.html.md.erb
and .gitkeep
. Delete the .gitkeep
file. This is a placeholder file from when you created the directory since git cannot track empty directories. A quick way to delete the file is to click .gitkeep
and then click the Delete
button./product
, /solutions
, /pricing
or any pages related to your page.How to create an analyst report page in 5 not-so-easy steps.
analyst_reports.yml
- https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/analyst_reports.yml- url: gartner-aro19
title: "Gartner Application Release Orchestration Report"
subtitle: "Gartner Cites GitLab as a Challenger in MQ for ARO"
resource_link: /resources/gartner-aro/
include_file: /analysts/includes/gartner-aro19
/analysts/includes/<url>
<analyst>-<report><year>
. Make a note of this url
as you'll need it later a few times throughout the process.#
at the beginning of the line. You need to coordinate with MPM to create a landing page to download the report to use as the resource link.</>
/sites/uncategorized/source/analysts/includes/
plus the file name for the report you are adding using the .html.md
file extension. <analyst>-<report><year>.html.md
/sites/uncategorized/source/analysts/includes/gartner-eapt20.html.md
/images/analysts/
folder.source
folder, then the images
folder, then the analysts
folder. This is kinda tricky because you have to scroll past a lot of folders to find the one you want. The folders are in alphabetical order.analysts
folder and click on the drop down and select “Upload file”. This is an important step. If you upload the file to a different folder then the image won’t show up on the page./sites/uncategorized/source/includes/forrester-reports.html.haml
file. Open it in the WebIDE.forrester-waves-container
This is a tricky step because the indentation needs to be exactly the same as the other sections. When you copy you need to copy all the spaces indenting the line. When you paste, be sure to paste with your current not indented at all. This should give you the same spacing. For example:
<!–– Gartner ARO 2019 ––>
.forrester-wave-row
.wave-row-content
= image_tag "/images/analysts/gartner-app-release.jpg", class: "forrester-wave-graphic", alt: "GitLab Cloud CI Forrester Wave thumbnail png"
.wave-row-content
%img.gartner-logo{ src: "/images/home/gartner-logo.svg", alt: "Gartner logo svg" }
.text-center.forrester-graphic-title
%p ARO Report
%p Gartner Cites GitLab as a Challenger in MQ for ARO
%a.btn.cta-btn.accent.margin-top20.reports-include-button-aro{ href: '/analysts/gartner-aro19/' } Read more
,
.wave-row-content, or
.text-center.forrester-graphic-title`. The phrases that start with a dot are CSS classes, so if you edit them the page will be formatted strangely..haml
file. You should only ever need to edit .md
and .yml
files.)= image_tag
line. Here you need to reference the image file that you uploaded in the previous step. The image file name here needs to exactly match what you named the file when you created it. It should be “kabaob case” - all lowercase letters with dashes instead of spaces.haml
, or possibly in a separate .yml
file that populates fields in the haml
file. The hello bar is an example of content in a .yml
file.Great care should be taken whenever moving pages on the website. Ideally, pages should never be moved without implementing an immediate 301 redirect.
The Inbound Marketing team can follows this process to create 301 redirects.
If you need to rename a page (e.g. change /company/culture/all-remote/part-remote
to /company/culture/all-remote/hybrid-remote
, as was achieved in this merge request), follow the below steps if using Web IDE.
redirects.yml
.
data/redirects.yml
. Define "sources", "target", and "comp_op" like so: - sources:
- /company/culture/all-remote/part-remote/
- /company/culture/all-remote/part-remote
target: /company/culture/all-remote/hybrid-remote/
comp_op: '='
When adding an image to a webpage, be sure that you optimize the image first.
hello-bar
)/source/includes/hello-bar.html.haml
.Categories and stages are defined in the product handbook. Stages are stored in data/stages.yml
and categories are stored in data/categories.yml
as the single source of truth for engineering and marketing.
These two files power various parts of the website including the homepage, product pages, and product categories handbook.
They are also used by the automated triage operation "Stage and group labels inference from category labels".
Below are attributes that can be added to a stage in data/stages.yml
. Each of these properties is accessed via stages.<stage_key>.foo
display_name
: the name of the Stage in sentence casepm
: the PM leader for this stagemarketing
: boolean, whether or not the stage is a "marketed" stage and should be displayedtw
: boolean, if supported by technical writingimage
: the logo for the stagedescription
: a short description of what the stage coversbody
: a longer-form description of what the stage coversdirection
: where the direction page can be located (ex: /direction/foo
)roadmap
: a URL to where the roadmap for the stage can be foundestablished
: the year the stage was established (ex: 2020
)lifecycle
: integer (1-7), where the stage falls in the devops lifecycleusage_driver_score
:the Product Usage Driver score, used on /handbook/product/investmentrevenue_driver_score
:the Revenue Driver score, used on /handbook/product/investmentsam_driver_score
:the Service Addressable Market score, used on /handbook/product/investmentstage_development_spend_percent
:analyst_reports
: a list of links to relevant analyst reports
analyst_reports.title
: the title of the reportanalyst_reports.url
: the URL of the reportrelated
: the stages related to this stagesection
: the section this stage belongs togroups
: a list of groups that belong to this stage. definitions for their properties belowBelow are attributes that can be added to a group in data/stages.yml
. Groups are defined in the groups
property of a stage. Each of these properties is accessed via stages.<stage_key>.groups.<group_key>.foo
name
: the name of the Group in sentence caselabel
: The group label in the gitlab-org
group.
By default, the group label is inferred from its name.
For instance, the import
group is represented by the
group::import
label in the gitlab-org
group.
This attribute allows to override that.
For instance, the gitlab-org
label for the Distribution Deploy
group is group::distribution
.focus
:pm
: the Product Managerpmm
: the Product Marketing Managercm
: the Content Marketerbackend_engineering_manager
: the Backend Engineering Managerfrontend_engineering_manager
: the Frontend Engineering Managersupport
: the Support Engineerpdm
: the Product Design Managerux
: a list of Product Designersuxr
: the User Experience Researchersets
: a list of Software Engineers in Testtech_writer
: the Technical Writerappsec_engineer
: the Application Security Engineerbe_team_tag
: the "tag" being used in the department
field in team.yml
for Backend Engineers on this teamfe_team_tag
: the "tag" being used in the department
field in team.yml
for Frontend Engineers on this teamcs_team_tag
: the "tag" being used in the department
field in team.yml
for Customer Success on this teaminternal_customers
: a list of internal customers/stakeholders for this groupinternal_customers.department
: the name of the internal customerinternal_customers.dri
: the DRI assigned for this relationshipusage_driver_score
: the Product Usage Driver score, used on /handbook/product/investmentasp_driver_score
: the ASP score, used on /handbook/product/investmentsam_driver_score
: the Served Addressable Market score, used on /handbook/product/investmentpi_gmau
: A link to the dashboard that displays GMAU for this grouppi_pgmau
: A link to the dashboard that displays Paid GMAU for this groupanalyst_reports
: A link to a location where relevant analyst reports are availablecomp_comparison
: A link to a location where comparisons with competitive products are availablecategories
: a list of categories that are owned by this group. definitions for their properties belowBelow are attributes that can be added to a category in data/categories.yml
. Each of these properties is accessed via categories.<category_key>.foo
.
name
: the name of the category in quotesstage
: what stage the category belongs to.label
: The category label in the gitlab-org
group.
By default, the category label is inferred from its name.
For instance, the Code Analytics
category is represented by the
Category:Code Analytics
label in the gitlab-org
group.
This attribute allows to override that.
For instance, the gitlab-org
label for the Kanban Boards
category is Category:Issue Boards
.feature_labels
: A list of all the feature labels that are associated with this category.
This list is used in the automated triage operation "Stage and group labels inference from category labels".marketing_page
(optional): the path of marketing page for the category. If you include a body
section, then a marketing page will be auto-generated at /product/${lowercase-category-name}
documentation
(optional): the URL of the docs page for the category, required if the category maturity is minimal or above.direction
(required): the URL of the category direction page. Optionally could be the URL of an issue, epic, or issue label search query if a direction page has not yet been created.description
: a short description of the category.roi
: true | false
should this category appear in the ROI calculator. (omitting the line is the same as false
)percent_of_focus
: A value of 0-1
detailing the percent of the group this category is assigned to's focus on this category in terms of developing improvementsavailable
: an ISO date for when the feature was or will be available.viable
: an ISO date for when the category will/did move from minimum to viable on the maturity handbook page.complete
: an ISO date for when the category will/did move from viable to complete on the maturity handbook page.lovable
: an ISO date for when the category will/did move from complete to loveable on the maturity handbook page.maturity
: the current maturity of the category on the maturity handbook page. Valid values are planned
, minimal
(available), viable
, complete
, and lovable
. Provided marketing = true
, a value of planned
will cause the category to appear in the "coming soon" section of the homepage, while other values will cause it to appear in the "Since 20XX GitLab added" section.marketing
: A value of true
will cause this category to appear on our marketing pages, in addition to our handbook. For the home page, a maturity
state is also required. Internationalizaion is a good example of a category the engineering team works on, but is not a "customer-facing category" that appears on marketing pages.body
: content added in markdown will be auto-generated and turned into a page at /product/<category>/
. Features and missing features sections are automatically added to the generated category pages based on what category a feature belongs to in features.yml
. c.f. Project Management (and auto-generated page from the body
section in categories.yml
) with Continuous Integration (a custom page.)opportunity
: values can be Core
, Adjacent
, Distant
- is this category considered part of our existing Core
DevOps platform, a directly Adjacent
set of capabilities or a Distant
vision for future breadth.differentiation
: values can be Winning
,Compelling
,Minimal
- is this category sufficiently differentiated from competitors to be considered capable of consistently winning
, providing an compelling
additive component to our single platform value or adding only minimal
differentiated value.ux_scorecard_score
: value should be a letter score, following the grading rubricux_scorecard_link
: should link to the specific issue for the scorecard for this category. More details on UX Scorecards heredogfooding_status
: values can be planned
, limited
, and exclusive
. Described in detail and used on /source/direction/dogfooding
dogfooding_issue
: should link to the specific issue tracking dogfooding for this issue, per the Dogfooding processdogfooding_group
: should list the right group/team/role/individual inside GitLab that should use the capabilityThere are five fields in categories.yml
that control a category's maturity. These work together to define what the maturity currently is, how it has evolved over time, and our plans to improve in the future.
maturity
which represents the current maturity of the categoryavailable
, viable
, complete
, and lovable
which are set to ISO dates when we achieved, or plan to achieve, the given maturity.To change or update the current maturity, set the maturity
field to the desired value: planned
(or empty), minimal
(available), viable
, complete
, and lovable
. Next, ensure that the historical and future maturity values are still consistent. For example, if you incremented the maturity of the category from viable to complete, you should also set the field complete
to the date of the GitLab release when it changed.
authentication_and_authorization:
name: "Authentication and Authorization"
stage: manage
documentation: https://docs.gitlab.com/ee/administration/auth/
vision: https://gitlab.com/groups/gitlab-org/-/epics/628
description: "GitLab features multiple auth mechanisms including LDAP (including Active Directory), OmniAuth, CAS, SAML, Okta, and Authentiq."
roi: true
available: 2017-10-01
viable: 2019-05-22
complete: 2019-12-22
lovable:
maturity: minimal
Due to their importance and wide usage throughout the company, changes to Stages, Groups, and Categories need to be reviewed. Open a merge request using the Category-Change
template to get started.
Major changes
Any change to a Stage or Group, or a significant change to a Category, is a major change. Examples of significant category changes include their names, their group membership, and presence on our marketing page.
Due to their impact, executive approval for major changes is required in addition to the PMs, PMMs, and EMs responsible. Follow the approval process defined on the categories page.
After merging, changes to feature categories will trickle down into error budgets at the start of next month when the Scalability group gets an automated issue like this one. Someone from the Projections team will change the ownership in the application, and update error budgets accordingly. As a product manager, nothing more needs to be done. The Projections team might reach out on the original merge request for clarification if needed.
Minor changes
Minor changes to Categories are generally routine changes, like updates to maturity and content links. For example, upon shipping an MVC the maturity would change to minimal
, and a link to the documentation would be added.
Approvals should be gathered from the responsible PMs, PMMs, and EMs. Also mention the relevant engineering and product directors, so they are aware of the changes. If changes are included in a release post, ensure the approval team and directors are mentioned on the MR.
To update the responsible person for a role, follow these steps:
data/stages.yml
at the relevant position e.g. pm: John Doe
.sites/handbook/source/includes/product/_categories-names.erb
Here's an example Merge Request.
If the person is not yet listed on the team page, please follow these instructions to add them.
All features and capabilities are listed in a single yaml file
(features.yml
) under the features
section.
It is the single source of truth for multiple pages across the website including:
To add a new feature, add a feature block to under the features:
section of the page. Add the following attributes:
link: https://docs.gitlab.com/ee/user/project/milestones/
true
or false
is this feature or capability available in this tier? gitlab_core
, gitlab_starter
, gitlab_premium
, gitlab_ultimate
. Note - it's assumed that any feature in a lower tier is also available in the higher tiers. For example a feature listed as in Core is also considered present in Starter, Premium and Ultimate.true
, false
or not_applicable
, defaults to true
. Is this feature or capability available for self-managed users? Use not_applicable
for features that do not apply to a self-managed service, for example the operational characteristics of our SaaS services.true
, false
or not_applicable
, defaults to true
. Is this feature or capability available for GitLab Dedicated? Use not_applicable
for features that do not apply to a SaaS service, such as the operational details of the service itself, like Fault-tolerant PostgreSQL
.true
, false
or not_applicable
, defaults to true
. Is this feature or capability available on GitLab.com? Because GitLab.com tiers map 1:1 to self-managed tiers setting this will automatically assign the GitLab.com tier. E.g. gitlab_core: true
+ gitlab_com: true
== GitLab.com Free
. Adding a tiers fields is what powers the tier badges on product pages and comparison pages, as well as powers the tier feature comparison of the pricing page. Use not_applicable
for features that do not apply to GitLab.com, such as the operational details of the service itself, like Fault-tolerant PostgreSQL
.devops_tools:
section such as jira:
, circle_ci:
, blackduck:
, etc. that does or does not have this feature. Holds a value of either true
or false
or partially
or is blank (indicating subfields with details should exist).
true
or false
or partially
: Examples of partially
are if a DevOps tool has some but not all of the feature described, or if they have the feature, but only through a plugin. If using partially
it is highly recommended to instead add details
as to what partially actually means (see next)valid
: Same as true
or false
or paritally
abovedetails
: A short statement about the details that need to be shared. For example: "supports 11 languages", or "only supported through 3rd party plug-ins"true
or false
: This currently has no impact on the primary pricing page, which is driven off themes. This does still apply to the (self-managed comparison and GitLab.com comparison) pages.For example:
- title: "Group Milestones"
description: "Create and manage milestones across projects, to work towards a target date from the group level. View all the issues for the milestone you’re currently working on across multiple projects."
link_description: "Learn more about Group Milestones"
link: https://docs.gitlab.com/ee/user/project/milestones/
solution: plan
category:
- portfolio_management
gitlab_core: true
gitlab_starter: true
gitlab_premium: true
gitlab_ultimate: true
gitlab_com: true
github_com: false
github_enterprise: false
bitbucket_org: false
bitbucket_data_center: false
gogs: false
jira:
valid: true
details: 'only through 3rd party extension'
ca_agile_central: false
Copy and paste this template:
- title: ""
description: ""
link_description: ""
link:
solution:
category:
-
gitlab_core:
gitlab_starter:
gitlab_premium:
gitlab_ultimate:
gitlab_com:
github_com:
The underlying data shown on the GitLab Learn page is available in https://gitlab.com/gitlab-com/marketing/digital-experience/buyer-experience/-/blob/main/content/learn/index.yml
To update the course content data:
Important guidelines to keep in mind:
The /resources
section of the website contains downloadable files and links to helpful content.
resources.yml
file.resources.yml
:- title:
url:
image: /images/resources/gitlab.png
type: Pick one --> 'Blog post' 'One-pager' 'Report' 'Webcast' 'White paper'
topics:
- Cloud native
- Code review
- Continuous delivery
- Continuous integration
- DevOps
- Git
- GitLab
- On-demand training
- Public Sector
- Security
- Software development
solutions:
- Distributed teams
- Accelerated delivery
- Executive visibility
- Project compliance
- Security and quality
/pdfs/resources/
.The Digital Experience team is incrementally adopting Netlify CMS for the marketing website. It offers a more user-friendly way of editing the marketing site, but comes with some limitations:
Read the Netlify CMS handbook page for up to date directions and status of the system.
If you're interested in getting a pulse on how recently the marketing website has been updated you can use a quick script to create a CSV in your local tmp/ folder with file names and their last commit date. Run it from the root directory of www-gitlab-com on your local machine:
ruby scripts/get-most-recent-commits.rb
It doesn't exactly map to URLs on about.GitLab.com, but this should be able to give you a pulse of what gets updated and how frequently. It only checks files in data/
and sites/uncategorized/
for now. For each file tracked in git in both of those folders, it grabs the file name and its most recent commit date (as known to git on your machine - so it will be incorrect if you haven't recently fetched or pulled from master).
Most of the data/
files map closely to a URL on the website. For instance, data/topic/ci-cd.yml
is the data for https://about.gitlab.com/topics/ci-cd/. So you should be able to scan through the CSV and get a good sense of how recently we've updated data files.
The files in sites/uncategorized
are a little more complex. Some of them are straightforward, like sites/uncategorized/source/get-started/index.html.md
is https://about.gitlab.com/get-started/
. Others are a little more meta, but still give you good information, like sites/uncategorized/source/includes/cms/topic/body.html.haml
will tell you how recently we have updated the layout for the body partials of the aforementioned topic pages.
Getting a direct mapping of each URL and its corresponding files is possible, but not practical. The only way we can find that out is by hooking into the Middleman sitemap, which is only available to us in templates. That means we have to have a Middleman instance running (or run the build process). But getting the most recent commit date requires having Ruby run a system call to run git log -1 --format=%cd --date=short /path/to/file
for each and every file. It takes a long time, and including that in Middleman somewhere would impact the overall pipeline negatively.
In the future, we could explore a custom Middleman extension that provides your data through the interface like http://localhost:7654/__middleman
has for most of the other config. But it would still be as slow as the system calls take (which is about 20ish minutes for the actual entire sitemap including handbook. Closer to 5-10 minutes for just marketing).
For best practices regarding testing and reviewing merge requests, please see our related handbook page for reviewing merge requests.
This is a link to our documentation on how to implement a video band.
Many of our forms are served through a third party tool, Marketo. Sometimes Marketo is blocked by an ad blocker or a strict web browser such as Brave. GDPR and CCPA (among other laws) require us to obtain consent before setting cookies and those cookies are required for many third party functions.
If you are having trouble using a form, please try updating your cookie settings to allow personalization (personal information) cookies. If that does not work, please try a different browser with a less strict adblocker and ensure our domain and subdomains (gitlab.com, about.gitlab.com, and page.gitlab.com) are not blocked.
If you have tried the above solutions but are still having trouble using a form, please file a bug report. Please note that if you do not provide all of the requested information we might be unable to reproduce the bug and therefore unable to fix it.
Because of how our infrastructure is setup, certain third party content (such as youtube embeds) or advanced javascript may not appear on review apps. If you are unsure of the cause, please contact us so we can help review what might be impacting your project.
If you need to temporarily preview an item in the review app before release, you can try to add the following attribute to the frontmatter of the file: manual_cookiebot: true
. Do not commit that change without removing it before your final merge. Alternately, you can follow this tutorial for steps on how to use developer tools to view a review-app video blocked by cookiebot.
On the about.gitlab.com website we have approval to use the customer logos lisited at the following link, Approved customer logos for promotion
Sometimes a merge train will get stuck in our www-gitlab-com repo pipelines. Please see this related issue for instructions on how to recover a stuck merge train.