All PRs to the LaunchDarkly-Docs repo will be addressed within five business days, often sooner. "Addressed" does not necessarily mean "merged" or "accepted." It means that a member of the LaunchDarkly docs team will acknowledge your PR within that timeframe.
In practical terms, we will likely merge your PR within five business days of submission.
Some larger PRs require back-and-forth iteration before they're ready to get published. If you're a partner or other party planning a large docs contribution to coincide with a feature release, buffer your time to accommodate for some discussion or review before your docs go live.
If you have a docs concern or contribution that you need addressed urgently, email [email protected].
We'll do our best to merge your PR as soon as we can, but we're a small team serving a large community. Thank you in advance for your patience.
Follow this process:
-
File a ticket in the Documentation Shortcut project. Summarize the changes you need in the ticket body. You can assign it to your squad or the epic related to your feature, but make sure it’s in the Documentation project!
-
Schedule a kickoff meeting with @Sarah Day (or invite her to the feature kickoff meeting). You can add other writers if you need to as well.
-
Two weeks before your feature launches, PR your docs updates into ld-docs-private. The squad-docs alias get added automatically, but you should also add other technical or product reviewers if you need.
-
Now the docs team gets your docs ready to ship! Expect to go back and forth with them in revisions once or twice before everyone agrees the docs are ready.
Learn more in Confluence.
You can make your contribution to the docs more likely to be accepted early by following our style guide and using our custom components.
If you want to write a good PR, here are some resources to get you started:
- The LaunchDarkly documentation style guide
- The LaunchDarkly documentation contributor's guide
- Information about our custom components
Our site runs with Gatsby, NPM, and Yarn. To run the site on your local machine, you may have to install some packages and dependencies.
Here's how to start:
- Clone the repo locally.
- Navigate to it in your terminal.
- Run the following command:
yarn && yarn startAs a shortcut:
yarn devThe site will build. Monitor the progress in your terminal, and when the build completes, navigate to localhost:8000.
You can also run in a fast development mode which omits all mdx images and most mdx content except for /home/getting-started, /home/flags and /home/contexts :
yarn && yarn dev-fastThis cuts the gatsby build time to just < 7 seconds as opposed to > 1 minute.
To run tests, read Running tests.
The easiest way to modify an existing topic is by opening a PR against it directly from the docs site by clicking the "Edit in GitHub" button on the topic page.
If you want to add a new topic from a local build, the src/content/topics folder contains all the docs markdown. You can also find an existing topic and modify it from here.
Need more help? The contributor's guide goes into a lot more detail about the structure and architecture of the repo.
If you encounter what looks like a Gatsby cache issue, you can clean the Gatsby cache before your build the site.
Here's how:
yarn cleanIf you still encounter issues, perform a clean-all to delete all possible caches:
yarn clean-allIf you're a new LaunchDarkly technical writer or other contributor accessing the repo for the first time, you must complete the following setup steps to access and make changes to ld-docs-private.
- Request access to the Dev repo.
- Follow steps 1-9 under New computer setup.
- Request admin access to ld-docs-private and LaunchDarkly-Docs. To learn more more about how the repos relate to each other, read Syncing content between ld-docs-private and LaunchDarkly-Docs.
When you open a docs PR, it creates a unique staging directory. The URL for that PR is linked in the PR page in the repo, and follows the pattern https://docs-stg.launchdarkly.com/nnnn/, where nnnn is your PR number. If the branch you are merging into has a name ending in -eap, then its content is additionally deployed to the staging site at https://docs-stg.launchdarkly.com/branch-name, where branch-name is something like your-feature-eap.
Staging is automatically refreshed on a push to each branch. To learn more, read Build & Deploy.
GitHub action automatically builds and deploys to staging on push to main.
If you want to manually deploy your own branch to staging, do this:
yarn deployThis builds Gatsby and upload the artifacts to the staging s3 bucket.
In your pull requests, add a line to the end of the pull request description like this:
/schedule 2022-12-31
Or if you need to specify the exact time, you can use an ISO 8601 date string:
/schedule 2022-12-31T15:45:00
Dates are in PT timezone. Any string that works with the new Date() constructor will work.
We use flags in Catfood under the Docs project. There are three environments: Development, Test and Production corresponding to local dev, staging and prod respectively.
You can use the gatsby-plugin-launchdarkly, to hide nav items behind a feature flag. To do this, add the flagKey property to the nav item you want to control with a flag in navigationData.json. Use the camel case version of the flag key, as shown below:
...
{
"label": "Your flag controlled nav item",
"path": "/home/getting-started/hiding-your-nav-behind-a-flag",
"flagKey": "myHiddenNav"
},
...To check local links in MDX files run
yarn test-linksTo validate external links locally, install lychee
brew install lycheeThen run
yarn lycheeTo run spellcheck locally, use
yarn spellcheck
To run our integration tests locally, make sure the dev server is running via yarn start, and
yarn cypressTo run them in headless mode,
yarn cypress:ciTo skip external link validation,
yarn cypress --env skip_external=trueAll of our tests are integrated into out CI/CI pipeline and most are guaranteed to run on every PR.
Local link checking and spellcheck run as part of the Testing GitHub action. External link link validation runs once per day as part of the Scheduled link check GitHub action.
All navigation data are stored in src/content/navigationData.json.
This is flattened at build time to autogenerate two files rootTopics.json and secondLevelTopics.json. The
flattened data are queryable via graphql and allows us to render the side nav more efficiently.
You can also flag navigation items. To learn more, please refer the section Flagging navigation items.
Please reach out to @scribblingfox if you need to log in to Algolia. She will be able to send you an invite.
To index mdx content and send to Algolia, add the following to your .env.development file:
ALGOLIA_ADMIN_KEY=insertValue
BUILD_DEV_ALGOLIA_INDEX=trueYou can get an admin key in the Algolia settings.
If no special environment is set, this will use the Docs_development index.
The convention for index names is {GATSBY_ALGOLIA_INDEX}_{ENVIRONMENT}. The environment variable can be set via
cli param GATSBY_ACTIVE_ENV. For example, for staging, you would run the following command:
"build-staging": "GATSBY_ACTIVE_ENV=staging gatsby build",This will create an algolia index called Pages_staging.
This repo uses Yarn PnP (zero-installs) to reduce build times.
When upgrading package versions, you must commit cache files such as .yarn/cache/... and .pnp.cjs into main along with the yarn.lock and package.json files.
To learn more about PnP, read the documentation.