This repository contains the Pantheon documentation as well as the tools to build local test environments.
- 2023/02: Pantheon Docs is now a Pantheon Front-End site running Gatsby 4.
- 2019/08: We've relaunched the project using Gatsby for faster development, and much faster page speed.
Our docs are written in Markdown and extended with MDX components. The pages live in source/content
. Read CONTRIBUTING for more details on contributing documentation improvements.
Read our Style Guide for our guidelines on how to write documentation.
-
MacOS or Linux system (untested with Bash on Windows)
-
Gatsby CLI:
npm install -g gatsby-cli
-
Alternatively, you can use Lando. Use Lando to bypass installing Node.js and the Gatsby CLI on your local machine. Lando requires a Docker version in the
2.1.0.0
-3.1.99
range.
This list of steps should work on a Mac with Homebrew:
brew install node
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash
nvm install 18
npm install -g gatsby-cli
Fork and clone this repository:
git clone git@github.com:pantheon-systems/documentation.git
cd documentation
We use the gatsby-remark-embed-snippet to use files from GitHub in our docs. Before you can build a local development site, you need to provide a GitHub token to the environment:
- Log in to GitHub and go to https://github.com/settings/tokens
- Click Generate new token.
- Give the token a name, expiration, and description.
- Select your GitHub user as the resource owner.
- For repository access, select Only select repositories and select your fork of this repository.
- Under Repository permissions, choose Access: Read-only from the Access dropdown button for Contents.
- Click Generate token.
Alternatively, if you'd rather create a classic-style token:
-
Log in to GitHub and go to https://github.com/settings/tokens
-
Click Generate new token (classic)
-
Give the token a name and click the public_repo checkbox, then the Generate Token button at the bottom
-
Copy the token to your clipboard
-
In the root
documentation
directory, create a new file called.env.development
and add (replacing$TOKENHASH
):GITHUB_API=$TOKENHASH
A GitHub Codespace can be used to test the site as well. To set up a Codespace, navigate to the branch you want to use as the base (e.g. main
) and click the Code dropdown.
This will take you to a VSCode-like interface with a Terminal window. From here, export your GitHub API token you created in the previous step using the following command (replacing $TOKENHASH
with your API token):
export GITHUB_API=$TOKENHASH
Now you can run npm ci
and npm start
in the Terminal panel at the bottom of the page. The docs site will build inside the Codespaces container and install Node dependencies just like it would on your local machine. When the Node server is running, a dialog box will appear at the bottom right corner asking if you want to open the Codespace in a browser and if you want to make the Codespace public.
Clicking on the link will take you to a live site that's running on the current branch of the repository. If you opted to make the Codespace public, you can share the link to others and they will be able to view the site after accepting a warning that they are visiting someone else's Codespace. If the Codespace was not made public, only your GitHub user will be able to see it.
You can open a Codespace (or load an existing Codespace) on a particular branch by first navigating to that branch in the GitHub repository. Alternately, if you already have the VSCode editor open, you can select a specific branch by clicking the branch name at the bottom left, then selecting the branch you would like to switch to in the panel that appears at the top of the screen. The Codespace will make the necessary adjustments and rebuild the docs site on that branch.
Codespaces is free for individuals for 60 hours of runtime for 2 cores, after which your user is billed for additional time. It's unclear whether Pantheon's Enterprise account would own billing, but as of this writing it appears to be billed on a per user basis. For this reason, it's important to not leave your Codespaces running when you're done with them.
From the documentation
directory:
npm ci
Still in the documentation
directory:
npm start
Use your local browser to navigate to localhost:8000/
.
Locally saved updates to docs are automatically refreshed in the browser.
Alternatively, you can use Lando. The lando start
command initiates the app, installs node dependencies, and starts the gatsby develop
server for you:
lando start
You can view the local environment at localhost:8000/
. Updates to docs are automatically refreshed in the browser.
We use Prettier to enforce code style on changed files. On each pull request to the repository, if any .js
, .jsx
, .ts
or .tsx
files are modified in the /src
directory, We run Prettier to check for code styling issues on the updated/changed files. If Prettier made any changes, those changes are automatically committed back to the PR (see example PR).
To automatically fix formatting issues across the entire /src
directory, run:
npm run format
Be cautious when running this command, as it will automatically fix any formatting issues it can.
To reduced the likelihood of regressions and bugs this site uses a few different testing tools:
Within the tests
directory there are a number of visual regression tests that can be run to compare the current state of the site to a PR preview or the live site.
These tests are meant to be run locally instead of CI as they have a high rate of false positives.
Unit tests for custom logic are written in in Vitest and can be executed with
npx vitest src/components
These tests are executed in CI via a GitHub Action.