Documentation and landing page for the KEDA project at keda.sh.
Are you using KEDA in production? Do you want to become a listed user? Say no more!
You can easily get listed by following these steps:
- Upload your logo to
static/img/logos/
(350x180) - Configure your company as a new user in
config.toml
(sorted alphabetically)
[[params.users]]
url = "https://coralogix.com/"
logo = "coralogix.gif"
Here's a good example of Coralogix becoming a listed user!
To build or serve the site locally, follow these steps:
- Fork and clone this repository (for local development only).
- Install the latest LTS release of Node, using nvm for example:
Note: on Windows, the argument to install is
$ nvm install --lts
lts
. - Get npm packages and other prerequisites:
$ npm install
- To build the site, run:
You'll find the generated site files under
$ npm run build
public
. - Serve the site locally at localhost:8888 using:
$ npm run serve
We welcome issues and PRs! For details, see Contributing to KEDA.
If you submit a PR, Netlify will automatically create a deploy preview so that you can view your changes. Once merged, Netlify automatically deploys to the production site keda.sh.
To see deploy logs and more, visit project's dashboard -- Netlify login required.
To add a new post to the KEDA blog:
$ hugo new blog/my-new-post.md
This creates a boilerplate Markdown file in content/blog/my-new-post.md
whose
contents you can modify. The following fields are required:
title
date
(inYYYY-MM-DD
format)author
To add documentation for a new KEDA scaler:
$ hugo new --kind scaler docs/<VERSION>/scalers/my-new-scaler.md
This creates a boilerplate Markdown file in
content/docs/<VERSION>/scalers/my-new-scaler.md
whose contents you can modify.
Make sure to update the following metadata fields:
title
availability
maintainer
description
In order to maintain the style consistency across different scalers, all the parameters which are listed have to be written using this convention:
- name - Description. (Values: x, y, z, Default: y, Optional, Extra Info)
If a parameter is required or doesn't have defined/default values, the missing info should be removed from the pattern.
Here are a few examples:
targetMetricValue
- Target value for your metric.metricFilter
- Aggregation method of the metric. (Values:max
,min
,average
,sum
,variance
, Default:average
, Optional)metricPeriod
- Granularity of the metric. (Default:300
, Optional)subscriptionName
- Name of the Azure Service Bus queue to scale on. (Optional, Required whentopicName
is specified)
To update the KEDA FAQ page, update the TOML file at
data/faq20.toml
. Here's an example question/answer pair:
[[qna]]
q = "How can I add a new question/answer pair?"
a = "You're looking at it! ๐"
To add a new section to the troubleshooting page:
$ hugo new troubleshooting/<VERSION>/my-new-issue.md
To adjust the order in which the troubleshooting tiles appear, use the weight
parameter in each page's metadata.
The KEDA documentation is versioned. Each version has its own subdirectory under content/docs. To add a new version, copy the directory for the most recent version. Here's an example:
$ cp -rf content/docs/<CurrentVersion> content/docs/<NewVersion>
By default, new documentation versions are not listed as available version so it's safe to make changes to them. After every release, the version will be published as new version.
Remember to create the folder for next version with already existing docs in current version.
Make sure that the version on content/docs/{next-version}/deploy.md
is updated
and uses the next version, instead of the current one.
Once a version is ready to be published, we must add the version to the
params.versions.docs
list in config.toml.
More recent versions should be placed first in the list (ordering does matter because the first element in that list is considered the latest version).
Note: Remember to prepare the next version.