-
Notifications
You must be signed in to change notification settings - Fork 459
Home
This page provides instructions for common docs tasks. It's intended for internal CockroachDB contributors working from branches in the docs repo rather than from external forks.
Note: With git
, there are many ways to reach the same outcome. The git
steps here are based on Jesse's current workflow. If there's a better/more efficient way to do something, please let him know. You can also use the GitHub Desktop app.
- Start Writing
- Get Reviewed
- Publish
- Release Notes
- Squash Commits
- Remove Commits
- Generated Docs
- Updating the Interactive SQL Help Text
- Cluster Settings/Session Variables
- Add Search Synonyms
When you're starting a new docs project:
-
Move to your copy of the docs repo:
cd src/github/cockroachdb/docs
. -
Make sure you're on the
master
branch:git checkout master
.This helps to prevent your new branch from inheriting commits from another branch. If that happens, though, you can always remove them.
-
Get any recent updates to
master
:git pull
. -
Create a new branch:
git checkout -b "<your branch name>"
. -
Write/edit markdown files in your text editor.
-
Build a local version of the docs to view your changes:
- Use
make standard
to build CockorachDB docs. - Use
make cockroachcloud
to build Managed CockroachDB docs.
- Use
-
Check the files you've changed:
git status
. -
Stage your changes for commit:
git add .
(stage all changed files) orgit add <filename>
(stage a specific file). -
Commit your changes:
git commit -m "<concise message describing changes>"
. -
If you've made lots of little commits that aren't meaningful on their own, squash some of them.
-
Start the Review workflow.
Once you're ready to have work reviewed:
-
Push your local branch to the server (first time):
git push -u origin <branch name>
. -
Go to the docs repo in the UI, create a pull request with a brief description.
TeamCity runs the PR through Jekyll, syncs the output to an S3 test environment, and posts a link to the test docs as a comment in the PR. It's a good idea to check that everything looks good there before moving on.
-
In the PR, assign your initial reviewer, generally the CockroachDB engineer responsible for, or knowledgable about, the product area you're documenting.
-
Edit your local branch based on feedback.
-
Push edits to the server:
git push origin <branch name>
. -
In the PR, assign someone from Docs to do a language/structure review. For new features, it's a good idea to assign someone from Product as well.
-
Once you get LGTM from the reviewers, merge the PR and delete the remote branch.
-
Switch to
master
:git checkout master
. -
Update
master
:git pull
. -
Delete the local PR branch:
git branch -d <branch name>
.
When you merge a PR, the changes are automatically published to our GitHub Pages account.
See the cockroach wiki.
While working, you'll likely make lots of little commits that aren't meaningful on their own. So before opening a PR, it's friendly to squash your commits down to one or a few meaningful ones. Here's how:
- Switch to your branch:
git checkout <branch name>
. - Run:
git rebase -i master
. This will list your branch's commits invi
. - Press
i
. - Reorder the commit lines so the commits you want to retain are at the top.
- For each commit that you want to squash/meld into the ones at the top, change
pick
tos
orsquash
. - Press
esc
+:wq
+enter
. This will save your changes and open a view of your commit messages invi
. - Press
i
. - If necessary, update the message of each commit you're keeping.
- Press
esc
+:wq
+enter
.
Note: After squashing commits, to push to an existing remote branch, you'll need to use the --force
flag, e.g., git push --force origin <branch name>
.
If you've somehow inherited unwanted commits from another branch, or if you simply want to remove a commit from your branch:
- Switch to your branch:
git checkout <branch name>
. - Run:
git rebase -i master
. This will list your branch's commits invi
. - Press
i
. - For each commit that you want to remove, change
pick
tod
ordrop
. - Press
esc
+:wq
+enter
. This will save your changes and open a view of your commit messages invi
. - Press
i
. - If necessary, update the message of each commit you're keeping.
- Press
esc
+:wq
+enter
.
Note: After removing commits, to push to an existing remote branch, you'll need to use the --force flag, e.g., git push --force origin .
When support for new SQL statements or functions is added or updated, in addition to documenting the updates, you need to generate new SQL syntax diagrams or function syntax tables. After generating the diagrams/tables, you need to add, commit, and push the changes to the docs
repo as a part of the documentation PR. When syntax or usage is updated, make sure that you regenerate the diagrams/tables and replace old ones!
We generate diagrams and tables from source code using an internal tool called docgen
. When you build cockroach
from source, you build a number of other binaries included in the cockroach
repo, including docgen
.
To build cockroach
(and docgen
) from source:
- Go to your local copy of the
cockroach
repo. $ git checkout master
$ git pull
-
$ make
(this takes a few minutes)
You can then install docgen
, which places the binary in your GOPATH
, and enables you to call it from any directory:
$ go install ./pkg/cmd/docgen
To save time, you can also just build docgen
by itself:
- Go to your local copy of the
cockroach
repo. $ git checkout master
$ git pull
$ make bin/docgen
$ go install ./pkg/cmd/docgen
After docgen
is installed, you can use it to generate diagrams and tables. docgen
has two commands: grammar
and functions
. docgen grammar
generates diagrams. docgen functions
generates functions. See SQL Diagrams and Functions for usage details. You can call also docgen --help
for basic usage instructions.
To generate SQL diagrams, use docgen grammar
. docgen grammar
has two commands: svg
and bnf
. docgen grammar svg
calls a Railroad Diagram generator tool that converts a BNF specification of SQL syntax to XHTML-formatted diagrams. docgen grammar svg
takes the diagram generator's XHTML output and converts it to proper HTML that we can use on our website. docgen grammar bnf
generates new BNF files from SQL grammar source code.
Before you generate the diagrams, you need to generate the most up-to-date BNF files with docgen grammar bnf
:
$ docgen grammar bnf <path to BNF output>
The cockroach
makefile calls docgen grammar bnf
to generate the BNF files to cockroach/docs/generated/sql/bnf
:
bin/.docgen_bnfs: bin/docgen
docgen grammar bnf docs/generated/sql/bnf --quiet
touch $@
So, every time you build cockroach
from source, new BNF files are generated. Note, however, that the Makefile does not call docgen grammar svg
to generate new diagrams from the BNF files. You need to do this manually.
By default, docgen grammar svg
calls the Railroad Diagram generator API. This API is undocumented, and subject to change. As of 2/10/2020, we strongly recommend downloading the Railroad JAR file from the employee Google Drive. This JAR file is also undocumented, but it is not subject to change (it's just a file sitting in our Google Drive). To get the JAR file:
- Navigate to Google Drive.
- Log in with your company email.
- Search "Railroad".
- Download the
Railroad.jar
file.
To use the Railroad JAR file, you must have Java 8 installed, and its JRE directory must be set as your JAVA_HOME
environment variable!
To set up Java 8 on macOS:
$ brew cask install adoptopenjdk8
- Add the following line to the top of your
~/.bash_profile
:export JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home
- Source the
.bash_profile
and check your Java version:$ source ~/.bash_profile
$ java -version
You should get `openjdk version "1.8.x" for the Java version.
After you install the Railroad JAR and Java 8, you are ready to generate new diagrams. To generate new diagrams, run docgen grammar svg
with the railroad
and filter
flags:
$ docgen grammar svg <path to BNF files> <path to diagram output> --railroad=<path>/Railroad.jar --filter=<BNF file to filter on>
The first argument after svg
specifies where the BNF files are located (usually in cockroachdb/cockroach/docs/generated/sql/bnf
). The second argument specifies where to generate the diagrams (usually in cockroachdb/docs/_includes/v20.1/sql/diagrams/
). The railroad
flag tells docgen
to use the JAR file instead of the API, and specifies where the Railroad.jar
file is located. The filter
flag filters the output on a specific BNF file name. If you specify no filter, docgen
will generate diagrams for all of the grammar (we don't recommend this).
When you generate new diagrams, make sure that you copy them over to the docs repo, in docs/_includes/<version>/sql/diagrams/
for each version of CockroachDB for which the changes were made!
To make our SQL diagrams more usable and intuitive, you can also:
- Rename parameters and unlink them so they don't point to our full SQL grammar.
- Inline parameters so users don't have to go to our full SQL grammar.
For info about generating SQL diagrams and making custom edits to diagrams, see SQL Grammar Railroad Diagram Changes.
The cockroach
makefile calls docgen
to generate function table markdown files to docs/generated/sql
:
When you generate new markdown tables, make sure that you copy them over to the docs repo, in docs/_includes/<version>/sql/
for each version of CockroachDB for which the changes were made.
To generate new function tables manually using docgen
:
cd $HOME/go/bin
-
./docgen functions $HOME/go/src/github.com/cockroachdb/docs/_includes/<version>/sql
for each version of CockroachDB for which the changes were made.
docgen
pulls the description strings and function syntax from the function definitions in cockroach/pkg/sql/sem/builtins/
. funcs.go
handles the function tables with function syntax for all supported functions.
When support for new SQL statements is added to cockroach
, or existing SQL statement support is updated, the pkg/sql/parser/sql.y
SQL grammar file is updated. Part of this update to the grammar file includes adding or editing the help text that describes the syntax and behavior of a particular statement. At the bottom of the help text is a link to that statement's documentation page, written as %SeeAlso: WEBDOCS/statement.html
.
Prior to v20.2, this help text was entirely the responsibility of the engineer(s) working on the statement. Because statements are often added before documentation is available, and because engineering is not responsible for user-facing SQL statement documentation, the links added could point to the wrong page, or to no page at all. Starting in v20.2, if a documentation page does not exist for a statement, there will be no doc link. It is the writer's responsibility to add the link in the help text.
When you add a documentation page for a new SQL statement, or when you update the page name for a SQL statement, you must add/update the link to that page in the statement's help text in pkg/sql/parser/sql.y
. To do this:
- Create a new branch on your local fork of the
cockroach
repo. Name it something like "docs-link-create-foo". - Open
pkg/sql/parser/sql.y
, and find theCREATE FOO
statement help text (it should start with// %Help: CREATE FOO
). - Locate the end of the help text (i.e., a break in the lines starting with
//
), and insert the following two lines:where// // %SeeAlso: WEBDOCS/create-foo.html
create-foo.md
is the name of the markdown file documenting theCREATE FOO
statement. - Save the file, stage and commit the change following the commit message guidelines (the commit title should begin with "
docs:
"), and then push the change to a new remote branch on yourcockroach
fork. - Open a pull request from the remote branch on your
cockroach
fork. In the PR description, link to the docs issue for the new statement, and, if it makes sense, to the feature PR incockroach
.
Tip: Look over the help text for a SQL statement before you start documenting the statement. This can help you come up with examples, better understand usage, and focus on which syntax/behavior aspects are the most important.
Note: When you change the name of a SQL statement docs file (or any docs file for that matter), always add redirect
s from the file's previous name!
Cluster settings and session variables are primarily documented on the cluster settings page and the SHOW session variable
and SET session variable
pages. The session variables table(there is one table, included in both SET
and SHOW
pages) needs to be updated manually. The cluster settings table is generated to a settings.html
file when you make cockroach from source. This file generates rows for all "public" cluster settings (i.e., cluster settings that won't destabilize the cluster - settings that users are expected to change). When you want to update this table in the docs, just fetch, pull, and make cockroach from source, and then copy and paste the generated settings.html file to the docs repo.
TBD
You can use the GitHub Desktop app to do most of the Docs workflow, but in an easier-to-understand UI instead of the command line.
To install GitHub Desktop:
- Navigate to GitHub Desktop.
- Click Download for macOS (or the relevant link for your OS).
- Follow the instructions to install.
- Sign in to your GitHub account.
If you have the Docs repo already on your computer:
- Navigate to File > Add Local Repository....
- Choose the repo file.
- Click Add Repository. The Docs repo will display in the left column.
If you don't have the Docs repo:
- In GitHub Desktop, navigate to File > Clone Repository.
- On the GitHub.com tab, find
cockroachdb/docs
. - Choose a location on your computer to save the Docs files.
- Click Clone. The Docs repo will display in the left column.
- On
master
, Fetch origin to get any recent updates. - Create a new branch off of
master
.- Go to Branch > New Branch.
- Enter a unique name for your branch.
- Click Create Branch.
- Write / edit markdown files in your text editor.
- Save your edits. A list of local changes will display in the left column of GitHub Desktop.
When you want to save your changes to your branch, go to GitHub Desktop and commit your changes to your branch:
- Enter a Summary, a concise message describing changes.
- Enter a Description (optional).
- Click Commit to [your-branch-name].
Once you're ready to have work reviewed:
- Click Publish branch to push your commits to the server.
- Go to Branch > Create Pull Request.
- GitHub will load in your browser. Click Create Pull Request.
- In the PR, assign your initial reviewer, generally the CockroachDB engineer responsible for, or knowledgable about, the product area you're documenting.
- Edit your local branch based on feedback.
- Commit changes
- To push edits to the server, click Push Origin.
- In the PR, assign someone from Docs to do a language/structure review. For new features, it's a good idea to assign someone from Product as well.
- Once you get LGTM from the reviewers, merge the PR and delete the remote branch.
- In GitHub Desktop, switch to
master
by using the Current Branch dropdown. - Click Fetch Origin to update your local version of
master
. - Delete the local PR branch.
- In GitHub Desktop, make sure your current branch is the PR branch.
- Navigate to Branch > Delete.
- Click Delete.