Where to find the docs and how to contribute
How to modify this website
The main landing page of this website can be modified in
Almost all of the content lives in the
content/en/docs directory. Here are some special cases.
./content/en/blogcontains all blog posts - make sure you update the front-matter for posts to show up correctly.
./external-sources/defines how files from other repositories are pulled in. We currently do this for Markdown files from the
make gen-contentpulls these in.)
- Flux CLI docs (
./content/en/docsbut pulled in through in
make gen-contentas well.
/static/_redirectsdefines redirects on https://fluxcd.io. Check out https://docs.netlify.com/routing/redirects/ for the syntax definition and how to test if things work.
Running the site locally
In order to run the Flux site locally, you need to install:
Hugo static site generator. Make sure to
install the “extended” variant of Hugo with support for the
Hugo Pipes feature and to check the
netlify.tomlconfiguration file for which version of Hugo you should install.
Once those tools are installed, fetch the assets necessary to run the site:
npm install make theme python3 -m pip install -r requirements.txt
Then run the site in “server” mode:
Navigate to http://localhost:1313 to see the site running in your browser. As you make updates to the site, the browser will immediately update to reflect those changes.
Publishing the site
The Flux website is published automatically by
Netlify when changes are pushed to the
main branch. The site does not need to be published manually.
When you submit a pull request to this repository, Netlify builds a “deploy preview” of your changes. You can see that preview by clicking on the deploy/netlify link in the pull request window.
Local Development (docker)
make docker-preview and wait until the following output appears:
Environment: "development" Serving pages from memory Web Server is available at //localhost:1313/ (bind address 0.0.0.0) Press Ctrl+C to stop
http://localhost:1313, where any changes will be visible from inside of the running container. Markdown files updated in
content/ should trigger a browser refresh as they are saved.
docker-preview target builds the theme, which takes a while and doesn’t need to be repeated unless you are making changes to the theme. On subsequent runs, running
make docker-serve instead will skip building the theme.
This depends on the Docker image
fluxcd/website:hugo-support which should be kept updated when the website’s build-time dependencies have changed; this image contains everything needed to run the docs locally.
If this doesn’t work, the image may be stale. The instructions to update it are below.
Remote Development (kubernetes / okteto CLI)
This works the same as local development above, but with the Okteto CLI you do not need to run a Linux machine or virtual machine on your local development environment.
First, make sure you are permitted to deploy pods on any local or remote Kubernetes cluster. Download the Okteto CLI for Windows, Mac, or Linux.
Okteto CLI is a light-weight client-side tool that replaces Docker with a remote cluster. You can run
hugo server remotely in this way; any changes to the local clone are synchronized to the cluster. The experience is basically the same as local development, (except that you won’t need to install Docker.)
make docker-serve, type
You can change the behavior in
okteto.yml according to the
Okteto Manifest Reference, for example adding a persistent volume can speed up the synchronization of the working directory files to the remote pod on repeated runs.
Updating the Development/preview container image
(For maintainers) Using a machine with
docker and logged in with an account that has permission to push to
docker.io/fluxcd/website repo, run
The dependencies of
docker-push are explained below. If the above worked then you are done, and should not need to read any further. Rebuilding
hugo takes a long time and should be avoided when the version hasn’t changed or it isn’t needed; run
make docker-push-support instead to skip building
docker-support image tag whenever build-time (or “serve”-time) dependencies have changed.
How is the Development container made?
These targets as explained below are run in the appropriate order as dependencies of
TODO: add a system/integration test for
websitethat verifies any changes have not broken
make docker-serve, for example by adding new dependencies without mentioning them in the
The Flux website has some build-time dependencies including Python3, PyYAML,
jq, (and potentially others that may be added in the future.) Flux-specific dependencies are prepared in an image that gets tagged as
This image is built from the
make docker-build-support to rebuild it locally, (or run as
make docker-push-support to build and also push.)
The Flux website also depends on a specific version of Hugo, which unfortunately does not provide docker images for each version. So we build it from source, with the
HUGO_BUILD_TAGS=extended build arg enabled.
make docker-push-hugo to build and also push this image target.
This will run
make hugo to get a shallow clone of the
gohugoio/hugo repository at the right
make docker-build-hugo to build a hugo container base image. (This target compiles
golibsass which is very large, and may take a while.)
These are all the dependencies of