Important Note: Many core pages of the GitLab website are now built from the Buyer Experience project: https://gitlab.com/gitlab-com/marketing/digital-experience/buyer-experience

This is the source for some of the https://about.gitlab.com/ site such as the public handbook, blog, and jobs. For a guide on how to start editing the website using git, see the handbook page on that topic.

The bulk of the marketing site, such as the homepage, pricing, and solutions are built by the Buyer Experience repository.

If you've already setup the project locally in the past, follow these simple steps to get back into contributing.

The git-page-update handbook page is the single source of truth for how to get this repository set up for local development.

We do, however, have additional details listed in the doc/development.md file. Regardless, you should start from the single source of truth for Ruby installation instructions and other dependencies.

Please see the contribution guidelines

Please follow the instructions in the handbook.

Edit data/pets.yml and add a new entry.

Images should be uploaded to sites/uncategorized/source/images/team/pets.

Read how to add a blog post.

Developer documentation for our instance of Netlify CMS.

How to update the releases page.

How to update the projects page.

How to add a press release page.

This section has moved to the doc/development.md "Production Build" section

This section has moved to the doc/development.md "Custom Generators" section

Thanks to the Review Apps, the www-gitlab-com project supports live reviewing of any website changes with every merge request. When a branch is pushed and the pipeline is successfully run, you can see a link pointing to the live environment in your merge request. The URL will be of the following scheme: <branch-name>.about.gitlab.com. Note that if you have underscores in your branch name, they will be replaced with dashes in the URL.

Beware that:

• To successfully deploy a Review App, the branch must exist in the www-gitlab-com repository. That means that branches from forks will not deploy a Review App (hence MRs from contributors). For that case, you should have at least Developer access to the www-gitlab-com project or gitlab-com group.
• The generation of the direction, wishlist, and releases pages are omitted in branches and is run only on master. This helps to shave off some time from the build process. That means you won't be able to preview these pages with Review Apps.

This section has moved to the doc/docker.md

If you only want Middleman to build a single file, you can do that via the --glob parameter. Here are a few things to keep in mind:

• The glob parameter must match the destination file.

• The --no-clean option should be included or Middleman will wipe out files that do not match the glob parameter.

For example, here's how to rebuild the Contribute page. Note how source/company/culture/index.html.md.erb is mapped to company/culture/contribute/index.html:

bundle exec middleman build --glob={company/culture/contribute/index.html} --no-clean

For blog posts, source/blog/posts/2017-05-23-attributes-of-successful-development-teams.html.md maps to blog/2017/05/23/attributes-of-successful-development-teams/index.html:

bundle exec middleman build --glob={2017/05/23/attributes-of-successful-development-teams/index.html} --no-clean

In case someone forgot the most important commands and is catting this file from the command line we end by listing them:

kill -kill `lsof -t -i tcp:4567`
bundle exec rake new_post
open -a "Google Chrome" http://localhost:4567
cd sites/mysite && bundle exec middleman

or to execute the last two commands, just run:

bin/run