- Notifications
You must be signed in to change notification settings - Fork0
🦍 Source code for docs.konghq.com website.
License
QubitPi/docs.konghq.com
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
This repository contains the source content and code forKong's documentation website. It's built usingJekyll and deployed withNetlify.
Here are some things you should know before getting started:
We're beginner-friendly. Whether you're a Technical Writer learning about docs-as-code or an engineer practicing your documentation skills, we welcome your involvement. If you'd like to contribute and don't have something in mind already, head on over toIssues. We've added
good first issue
labels on beginner-friendly issues.We need more help in some areas. We'd especially love some help withplugin documentation.
Community is a priority for us. Before submitting an issue or pull request, make sure to review ourContributing Guide.
Some of our docs aregenerated.
We are currently accepting plugin submissions to our plugin hub from trusted technical partners, on a limited basis. For more information, see theKong Partners page.
For minor changes, use the GitHub UI via the "Edit this page" button on any docs page, or useGitHub Codespaces.
For anything other than minor changes,clone the repository onto your local machine and build locally. Once you've installed all of the tools required, you can use ourMakefile
to build the docs:
# Install dependenciesmake install# Create local .env file# OAS Pages require VITE_PORTAL_API_URL to be set in your current environment, it should match the Kong supplied portal URLcp .env.example .env# Build the site and watch for changesmake run
Building the entire docs site can take a while.To speed up build times, you can generate a specific subset of products and their versions by setting theKONG_PRODUCTS
environment variable.This variable takes a comma-separated list of products, each followed by a colon and a semicolon-separated list of versions. The format is:
KONG_PRODUCTS='<product>:<version>;<version>,<product>:<version>,hub'
For example, running
KONG_PRODUCTS='gateway:2.8.x;3.3.x,mesh:2.2.x,hub' make run
will generate the plugin hub, mesh version2.2.x
, and gateway versions2.8.x
and3.3.x
.Wildcard matching is supported for both products and versions:
KONG_PRODUCTS='gateway:3.*'
and
KONG_PRODUCTS='*:latest'
The docs site will be available athttp://localhost:8888.
When raising a pull request, it's useful to indicate what type of review you're looking for from the team. To help with this, we've added the following labels:
review:copyedit
: Request for writer review.review:general
: Review for general accuracy and presentation. Does the doc work? Does it output correctly?review:tech
: Request for technical review, usually internal to docs. We normally use this for docs platform work.review:sme
: Request for SME review, external to the docs team.
At least one of these labels must be applied to a PR or the build will fail.
For troubleshooting instructions, see thetroubleshooting documentation.
If you have contributed a plugin to the Kong Plugin Hub, you can add a Kong badge to your plugin README.
Use the following, where you replacetest
with your plugin name andlink-to-docs
with a link to the Kong docs for your plugin.
[](link-to-docs)
SeeIssue #908 for more information. Note that we're not currently hosting assets for badges.
We usefetch
,cheerio
, andjest
for testing. To run tests, first build the site, then run:make build
followed bymake smoke
.
For more information, review theTesting documentation.
We run various checks at build time. Some checks can be manually approved using labels like:
ci:manual-approve:link-validation
For more information, review thecontinuous integration documentation.
The following links contain information about the docs publishing platform: