This repository holds source code for Kong's documentation website. It's built using Jekyll and deployed with Netlify.
Here are some things to know before you get started:
-
We're beginner-friendly. Whether you're a Technical Writer getting into code-as-docs or an engineer practicing your documentation skills, we highly encourage your involvement in our project. If you'd like to contribute and don't have something in mind already, head on over to Issues. We've added
good first issuelabels on beginner-friendly issues. -
We need more help in some areas. We'd especially love some help with plugin documentation.
-
Some of our docs are auto-generated.
All PRs for these docs should be opened over at the Kong/kong repository.
For Gateway Enterprise configuration reference and PDK reference documentation, open an issue on this repo and we'll update the docs.
-
Community is a priority for us. Before submitting an issue or PR, please review our Contributing Guide.
-
We are currently accepting plugin submissions, on a limited basis, from trusted technical partners to our plugin hub. To learn more about our partner program, see our Kong Partners page.
For anything other than minor changes, clone the repository onto your local machine and build locally. We offer the option to run your project locally with Docker, gulp, and npm.
- Docker (You will not need to run the Docker container via Docker Desktop.)
Start the Docker container (this installs dependencies for you and may take a few minutes):
make develop
If you have issues, run:
make clean
- gulp installed globally
Install dependencies:
make install
Run the project:
make run
If you have issues, run:
make clean
Install dependencies:
gem install bundler
npm install
Run the project:
npm start
If you have contributed a plugin, we welcome you to add a Kong badge to your plugin README.
Use the following, where you replace test with your plugin name and link-to-docs with a link to the Kong docs for your plugin.
[](link-to-docs)
Here's how the badge looks:
See Issue #908 for more information. Note that we're not currently hosting assets for badges.
This section is for Kong source code maintainers. You won't need to do anything here if you're contributing to this repo!
The PDK docs, Admin API docs, cli.md and configuration.md for each release are generated from the Kong source code.
To generate them, go to the Kong/kong repo and run:
scripts/autodoc <docs-folder> <kong-version>
For example:
cd /path/to/kong
scripts/autodoc ../docs.konghq.com 2.4.x
This example assumes that the Kong/docs.konghq.com repo is cloned into the
same directory as the Kong/kong repo, and that you want to generate the docs
for version 2.4.x. Adjust the paths and version as needed.
After everything is generated, review, open a branch with the changes, send a pull request, and review the changes.
You usually want to open a PR against a release/* branch. For example, in the
example above the branch was release/2.4.
cd docs.konghq.com
git fetch --all
git checkout release/2.4
git checkout -b release/2.4-autodocos
git add -A .
git commit -m "docs(2.4.x) add autodocs"
git push
Then open a pull request against release/2.4.
Tests for this site are written using rspec and capybara with the apparition driver.
You'll need Google Chrome installed to run these tests
To run the tests, you must first build the site by running make build before running make rspec
Many of the tests are smoke tests to check issues that occurred whilst adding caching to the site, such as ensuring that the side navigation isn't cached.
To add your own tests, look in the spec directory and use home_spec.rb as a sample. You specify which URL to visit and then a CSS selector to search for, before asserting that the contents match what you expect.
it "has the 'Welcome to Kong' header" do
visit "/"
expect(find(".landing-page h1").text).to eq("Welcome to Kong Docs")
endThis test framework can also be used to test behaviour added with JavaScript, but we do not have any examples at this time
We run various quality checks at build time to ensure that the documentation is maintainable.G
The include-check.sh script checks for any files in the app/_includes folder that depend on a page.* variable (e.g. page.url). This is not compatible with the include_cached gem that we use, and so using page.* in an include will fail the build.
To run the script locally, open a terminal and run
./include-check.shwhilst in the documentation folder. If there is no output, everything is successful
In the following example, we can see that deployment-options-k8s.md uses a page.* variable, and that the include is used in the kong-for-kubernetes.md file:
❯ ./include-check.sh
Page variables must not be used in includes.
Pass them in via include_cached instead
Files that currently use page.*:
File: app/_includes/md/2.5.x/deployment-options-k8s.md
via:
app/enterprise/2.5.x/deployment/installation/kong-for-kubernetes.md
Here are sample contents for those files:
In kong-for-kubernetes.md:
{% include_cached app/_includes/md/2.5.x/deployment-options-k8s.md }
In deployment-options-k8s:
This is an include that uses {{ page.url }}
To resolve this, the two files should be updated to pass in the URL when include_cached is called:
In kong-for-kubernetes.md:
{% include_cached app/_includes/md/2.5.x/deployment-options-k8s.md url=page.url }
In deployment-options-k8s:
This is an include that uses {{ include.url }}
The include_cached gem uses all passed parameters as the cache lookup key, and this ensures that all required permutations of an include file will be generated.