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 Strategic 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:
WIP:
.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
---
layout: markdown_page
title: ""
---
## Subheading
Here is your first paragraph replace this text.
index.html.md
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 on the correct branch is to click on "edit" in the changes tab of your MR. This will open the file editor. click "cancel" and dismiss the popup that says "all changes will be lost". This will then place you in the file view for the .gitkeep
file on your branch. Click the "delete" button to delete the file./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.
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/
screenshot_url: 28-group-milestones.png
Just put the filename of the screenshot. Feature screenshots must go in the following directory: 'images/feature_page/screenshots/'.true
or false
is this feature or capability available in this tier? gitlab_core
, gitlab_starter
, gitlab_premium
, gitlab_ultimate
true
, false
or not_applicable
. 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 iteslf, 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/
screenshot_url: 'images/feature_page/screenshots/28-group-milestones.png'
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:
screenshot_url: ''
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/www-gitlab-com/-/tree/master/data/learn
To update the course content data:
Please avoid leaving any classification fields empty if they apply, since that would prevent the course from appearing in the appropriate filtered results. If a value for a data field is not yet available, for example the url for a future course, leave the field empty.
Important guidelines to keep in mind:
When creating new pages to list subsets of our learning resources, you should make the lists autogenerate based on the SSOT learn.yml file. Here are a few examples of how to do this, you can edit these to generate other variations based on the course attributes available at classification.yml.
List of courses for a specific use case
This embedded ruby (erb) code generates a list of courses in from learn.yml filtering for only courses tagged with the use_case of "Continuous Integration". This will work on erb pages (e.g., index.html.md.erb).
<% data.learn.learn.select{|course| course.use_case == "Continuous Integration"}.sort_by(&:name).each do |course| %>
<%= "- [#{course.name}](#{course.url})" %>
<% end %>
List of certifications
This embedded ruby (erb) code generates a table from learn.yml with only those courses tagged as a certification and as available to the public. This code generates the table on our Public GitLab Certifications page. This will work on erb pages (e.g., index.html.md.erb).
| Use Case | Certification | Level |
| --- | --- | --- |
<% data.learn.learn.select{|course| course.assessment == "Certification" && course.confidentiality == "Public" && course.live_date && Date.parse(course.live_date) <= Date.today}.each do |course| %>
<%= "| #{course.use_case} | [#{course.name}](#{course.url}) | #{course.level} |" %>
<% end %>
List of learning materials by use case in table form You can see the source code on this page for an example on how to build a page with headers based on the classification.yml file and then for each header (use case in this case) build a table with the relevant course data. This will work on erb pages (e.g., index.html.md.erb).
<% data.learn.classification["use-case"].categories.each do |use_case| %>
<% course_list = data.learn.learn.select{|course| course.use_case == use_case.name && course.confidentiality == "Public" && course.live_date && Date.parse(course.live_date)} %>
<% next if course_list.empty? %>
<%= "## #{use_case.name}" %>
| Course | Registration | Assessment |
| ------ | --------------- | ---------- |
<% course_list.each do |course| %>
<%= "| [#{course.name}](#{course.url}) | #{course.registration} | #{course.assessment} |" %>
<% end %>
<% end %>
The /devops-tools
section of the website shows info about DevOps tools and a feature comparison of those tools to GitLab. Comparison pages are auto-generated from features.yml
and devops_tools_list.yml
. All you need to do is add a tool to the devops_tools
section in devops_tools_list.yml
and add that tool id to some features and the page will be created.
To add a new comparison page:
devops_tools_list.yml
devops_tools
section add a tool.Although the summary
and include_file
fields are not strictly required by the parser in order to build the page, every tool should have at least one paragraph summarizing the comparison using EITHER the summary
field or the include_file
field (see below for details). summary
only is deprecated. Use include_file
method whenever possible.
travis_ci
)/images/logos/
directory.md
) file that will be embedded on the page. Here is where you can add more robust content about the tool. Please use the template under /source/devops-tools/misc/tool-template.html.md
and store your new file under /source/devops-tools/TOOLNAME/index.html.md
.|
) then add content in markdown indented on the next line. Be sure to add on additional empty line after your content.For example:
With include_file
(preferred method):
jenkins:
name: 'Jenkins'
logo: '/images/devops-tools/jenkins-logo.svg'
category:
- ci
- cd
include_file: devops-tools/jenkins/index.html.md.erb
With summary
(deprecated method):
chef:
name: 'Chef'
logo: '/images/devops-tools/chef.png'
category:
- infrastructure_configuration
summary: |
Chef is a configuration management tool that enables deployment and maintenance of state for large scale infrastructure. Chef excels as managing legacy infrastructure like physical servers and VMs. Chef was designed before widespread container adoption and does not implement Kubernetes natively.
GitLab is a complete DevOps platform, delivered as a single application that includes not only configuration management, but also capabilities for project management, source code management, CI/CD, and monitoring. GitLab is designed for Kubernetes and cloud native applications.
GitLab can be used together with Chef to enable VM and bare metal configuration management. For Cloud Native applications run on Kubernetes, Chef is not required and GitLab can provide all the functionality natively.
Copy and past this template:
unique_tool_id:
name:
logo: '/images/logos/TOOLNAME.png'
category:
-
include_file: 'devops-tools/TOOLNAME/index.html.md'
Be sure to add features that GitLab has that the other tool doesn't and also features the other tool has that GitLab doesn't so that our comparison are transparent and honest (ie. this shouldn't be one sided).
tool id
and then true
, false
, or partially
to indicate support for the feature (what does partially mean?) Add the same details for gitlab tiers. Adding a tool id to a feature is what causes it to show up on the comparison page for that tool. (e.g. if you don't want a feature to show up on a comparison page remove the tool id line from that feature.)For example:
- title: "Free CI/CD with shared or personal Runners"
capability: true
description: "GitLab.com has shared Runners that allow you to use GitLab CI/CD completely free up to 2000 build minutes for private projects and unlimited for public projects. Alternatively, you can set up your own Runner for faster build processing, unlimited build minutes, or special requirements."
link_description: "Explore GitLab.com offerings"
link: /gitlab-com
solution: gitlab_com
gitlab_core: true
gitlab_starter: true
gitlab_premium: true
gitlab_ultimate: true
gitlab_com: true
github_com: false
bitbucket_org: 'partially'
gitlab_ci: true
codestar: false
- title: "Domain Specific Language"
description: "A Domain Specific Language (DSL) for defining infrastructure configuration allows thinking in resources, not files or commands to write declarative rather than procedural code."
# link_description: ""
# link: ''
solution: missing
gitlab_core: false
gitlab_starter: false
gitlab_premium: false
gitlab_ultimate: false
puppet: true
chef: false
/devops-tools/tool-vs-gitlab.html
and you should see it on the
devops-tools table on the main page.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.