registry-operator / adr

Collection of Architectural Decision Records (ADRs)
The Unlicense
0 stars 2 forks source link

[registry-operator]: static site generator for documentation #5

Closed shanduur closed 2 months ago

shanduur commented 4 months ago

Context and Problem Statement

Effective documentation is paramount for the successful adoption and utilisation of the registry-operator, a robust tool tailored for managing CNCF Distribution Registry instances. As developers and DevOps teams engage with the registry-operator, they require comprehensive, easily accessible documentation to streamline deployment, scaling, and management tasks.

The choice of documentation framework or static site generator is crucial to ensure that the documentation meets the needs of our users. Templating flexibility, support for custom scripts, and availability of extra plugins for enhancing functionality are key factors to consider in this decision-making process.

Considered Options

shanduur commented 4 months ago

Bootstrapping

  1. Docsy

    hugo new site .
    hugo mod init github.com/registry-operator/docs
    hugo mod get github.com/google/docsy@v0.9.1
    echo '[module]' >> hugo.toml
    echo '  proxy = "direct"' >> hugo.toml
    echo '  [module.hugoVersion]' >> hugo.toml
    echo '    extended = true' >> hugo.toml
    echo '    min = "0.73.0"' >> hugo.toml
    echo '  [[module.imports]]' >> hugo.toml
    echo '    path = "github.com/google/docsy"' >> hugo.toml
    echo '    disable = false' >> hugo.toml

    This produces the following file structure:

    registry-operator.docsy
    ├── archetypes
    │   └── default.md
    ├── assets
    ├── content
    ├── data
    ├── go.mod
    ├── go.sum
    ├── hugo.toml
    ├── i18n
    ├── layouts
    ├── public
    │   ├── 404.html
    │   ├── categories
    │   │   ├── index.html
    │   │   └── index.xml
    │   ├── css
    │   │   └── prism.css
    │   ├── favicons
    │   │   ├── android-144x144.png
    │   │   ├── android-192x192.png
    │   │   ├── android-36x36.png
    │   │   ├── android-48x48.png
    │   │   ├── android-72x72.png
    │   │   ├── android-96x96.png
    │   │   ├── apple-touch-icon-180x180.png
    │   │   ├── favicon-1024.png
    │   │   ├── favicon-16x16.png
    │   │   ├── favicon-256.png
    │   │   ├── favicon-32x32.png
    │   │   ├── favicon.ico
    │   │   ├── pwa-192x192.png
    │   │   ├── pwa-512x512.png
    │   │   ├── tile150x150.png
    │   │   ├── tile310x150.png
    │   │   ├── tile310x310.png
    │   │   └── tile70x70.png
    │   ├── index.html
    │   ├── index.xml
    │   ├── js
    │   │   ├── click-to-copy.js
    │   │   ├── deflate.js
    │   │   ├── main.js
    │   │   ├── prism.js
    │   │   └── tabpane-persist.js
    │   ├── scss
    │   │   ├── main.css
    │   │   └── main.css.map
    │   ├── sitemap.xml
    │   ├── tags
    │   │   ├── index.html
    │   │   └── index.xml
    │   └── webfonts
    │       ├── fa-brands-400.ttf
    │       ├── fa-brands-400.woff2
    │       ├── fa-regular-400.ttf
    │       ├── fa-regular-400.woff2
    │       ├── fa-solid-900.ttf
    │       ├── fa-solid-900.woff2
    │       ├── fa-v4compatibility.ttf
    │       └── fa-v4compatibility.woff2
    ├── resources
    │   └── _gen
    │       └── assets
    │           └── scss
    │               ├── main.scss_3f90599f3717b4a4920df16fdcadce3d.content
    │               └── main.scss_3f90599f3717b4a4920df16fdcadce3d.json
    ├── static
    └── themes

    Which looks like this:

    image
  2. Docusaurus

    npx create-docusaurus@latest registry-operator classic

    This produces the following file structure:

    registry-operator.mkdocs
    ├── docs
    │   └── index.md
    ├── mkdocs.yml
    └── venv
        └── ...

    Which looks like this:

    image
  3. Doks

    npm create hyas@latest -- --template doks
    npm install

    This produces the following file structure:

    registry-operator.doks
    ├── LICENSE
    ├── assets
    │   ├── cover.png
    │   ├── favicon.ico
    │   ├── favicon.png
    │   ├── favicon.svg
    │   ├── images
    │   ├── js
    │   │   └── custom.js
    │   ├── mask-icon.svg
    │   ├── scss
    │   │   └── common
    │   │       ├── _custom.scss
    │   │       └── _variables-custom.scss
    │   └── svgs
    ├── config
    │   ├── _default
    │   │   ├── hugo.toml
    │   │   ├── languages.toml
    │   │   ├── markup.toml
    │   │   ├── menus
    │   │   │   ├── menus.en.toml
    │   │   │   └── menus.nl.toml
    │   │   ├── module.toml
    │   │   └── params.toml
    │   ├── babel.config.js
    │   ├── next
    │   │   └── hugo.toml
    │   ├── postcss.config.js
    │   └── production
    │       └── hugo.toml
    ├── content
    │   ├── _index.md
    │   ├── blog
    │   │   ├── _index.md
    │   │   └── example
    │   │       └── index.md
    │   ├── docs
    │   │   ├── _index.md
    │   │   ├── guides
    │   │   │   ├── _index.md
    │   │   │   └── example.md
    │   │   └── reference
    │   │       ├── _index.md
    │   │       └── example.md
    │   └── privacy.md
    ├── layouts
    │   ├── index.html
    │   └── partials
    │       ├── footer
    │       │   └── script-footer-custom.html
    │       └── head
    │           ├── custom-head.html
    │           └── script-header.html
    ├── netlify.toml
    ├── node_modules
    │   └── ...
    ├── package.json
    └── static

    Which looks like this:

    image
  4. Material for MKDocs

    python3 -m venv venv && source ./venv/bin/activate
    pip install mkdocs-material
    mkdocs new .
    echo 'theme:' >> mkdocs.yml
    echo '  name: material' >> mkdocs.yml

    This produces the following file structure:

    registry-operator.mkdocs
    ├── docs
    │   └── index.md
    ├── mkdocs.yml
    └── venv
        └── ...

    Which looks like this:

    image
  5. Zola

    zola init

    This produces the following file structure:

    registry-operator.zola
    ├── config.toml
    ├── content
    ├── sass
    ├── static
    ├── templates
    └── themes

    Which looks like this:

    image
  6. Cobalt

    cobalt init

    This produces the following file structure:

    registry-operator.cobalt
    ├── _cobalt.yml
    ├── _defaults
    │   ├── pages.md
    │   └── posts.md
    ├── _layouts
    │   └── default.liquid
    ├── index.md
    └── posts
        └── post-1.md

    Which looks like this:

    image

Versioning

Examples

  1. Docsy:
  2. Docusaurus:
  3. Doks:
  4. Material for MKDocs:
  5. Zola:
  6. Cobalt:
shanduur commented 4 months ago

My initial thoughts:

  1. Using MKDocs and Hugo+Docsy will make dependency management much easier, as we can integrate it into Dependabot. MKDocs is using standard requirements.txt file, Hugo makes use of go.mod file.
  2. From my experience, it might be easier to keep go.mod file up-to-date and prevent breaking changes.
  3. Both Doks and Docusaurus are quite heavily dependent on Node.js. Even if Node.js is used for basic scripting, I think we need to check how those two integrate with things like Dependabot or Renovate, and how likely are the breaking changes.
  4. Produced templates differ a lot - I really like simplicity of Material for MKDocs, but Doks looks best in my opinion. Docsy is plain - scarry plain, literally the default is nothing.
  5. I really don't like how some tables look like for Doks, e.g. here. Especially because the vertical scroll in the table is unintuitive. In contrast, tables generated by MKDocs look really good here.
niesmaczne commented 3 months ago

I’ve glanced over on those frameworks, and based on the resources available, Docsy seems like the best choice - the documentation is very useful, there is a big community around that.

However I think there are some cons to all provided examples - almost all of them are plain, with large walls of text lacking visual differentiation. This causes the documents to be hard to read and search. The biggest issue comes from color scheme of code blocks - they are blending too much with other parts of text.

Another issue is lack of global vertical menu on the side, especially in the mobile version. Good option is to have two separate menus (at least in desktop version) - one for different pages, and other for sections on current page.

I think that with proper customization of Docsy, we would achieve easy to read and follow documentation, that will be useful for both neurotypical and neurodivergent users.