Giter Club home page Giter Club logo

labdoc's Introduction

labdoc

labdoc icon

Automatically generate documentation for GitLab CI/CD components and CI/CD pipelines.

What is labdoc?

labdoc currently focuses on generating documentation for GitLab CI/CD components. For an example, check out the labdoc component documentation, which is generated with labdoc.

In the future, the focus might shift to generating documentation for GitLab CI/CD Pipelines in general.

Getting Started

Install labdoc

Via Homebrew

brew install erNail/tap/labdoc

Via Binary

Check the releases for the available binaries. Download the correct binary and add it to your $PATH.

Via Go

go install github.com/erNail/labdoc

Via Container

docker pull ernail/labdoc:<LATEST_GITHUB_RELEASE_VERSION>

From Source

Check out this repository and run the following:

go build

Add the resulting binary to your $PATH.

Run labdoc

Prepare your GitLab CI/CD components

labdoc currently expects all your CI/CD components to be in a directory, with all files on the root level. By default, labdoc will use the templates directory.

The documentation is generated from the spec.inputs.*.description keywords, and from the comments above the spec and the job keywords. Below is a minimal example:

---
# This comment will be used as description for the component
spec:
  inputs:
    my-input:
      description: "This is used as description for the input"
    my-other-input:
      description: >-
        This is a multiline input.
        Since this output is used in a table, the `>-` is used to remove any newline characters
...

---
# This comment will be used as description for the job
my-job:
  script: "echo Hello"
...

Generate Documentation

labdoc generate --repoUrl github.com/erNail/labdoc

This will generate a README.md in the templates directory.

The --repoUrl flag is required to generate the instructions on how to include your components.

Change the documentation output directory

labdoc generate --repoUrl github.com/erNail/labdoc --outputFile my/custom/path/README.md

Change the component directory

labdoc generate --repoUrl github.com/erNail/labdoc --componentDir my-components

Check if the documentation is up-to-date

labdoc generate --repoUrl github.com/erNail/labdoc --check

This command will not write the documentation to a file. It will only check if there is already a documentation, and if the content would change.

If the content remains unchanged, the command will exit with code 0. If there is no documentation, or the existing documentation would change, the command will exit with code 2.

Include the version in the usage instructions

labdoc generate --repoUrl github.com/erNail/labdoc --version 1.0.0

By default, labdoc will generate instructions on how to include your component in other CI/CD pipelines. If no version is specified, it will use latest as the version to use for the include.

Custom Documentation Template

By default, labdoc will generate documentation based on the documentation template located in this repository.

You can create your own template and use it to generate documentation. Simply create a file that uses Go Templating syntax and the type ComponentDocumentation, then run the following:

labdoc generate --repoUrl github.com/erNail/labdoc --template templates/README.md.gotmpl

More Details

For more details about the labdoc command, run the following:

labdoc -h

pre-commit Hook

You can run labdoc via pre-commit. Add the following to your .pre-commit-config.yml:

repos:
  - repo: "https://github.com/erNail/labdoc"
    rev: "<LATEST_GITHUB_RELEASE_VERSION>"
    hooks:
      - id: "labdoc-generate"
        args:
          - "--repoUrl=gitlab.com/erNail/labdoc"

GitLab CI/CD Component

labdoc can be added to your GitLab CI/CD Pipeline as component. Check the component documentation generated by labdoc for more details.

Limitations

  • labdoc currently only supports reading CI/CD component files from a directory with all files on the root level. These file names will be used as the component names.
  • labdoc currently expects all components to define spec:inputs and at least one job. Not defining one or the other can lead to unwanted behavior.
  • As a result of this, labdoc is currently not able to handle components that only include other components or GitLab CI/CD files.

Planned Features

Please check the open GitHub Issues to get an overview of the planned features.

Development

Dependencies

To use all of the functionality listed below, you need to install all dependencies listed in the dev container setup script. If you are using this repositories dev container, you already have all dependencies installed.

Testing

task test

Linting

task lint

Running

task run -- --help
task run-generate

Building

task build

Building Container Images

task build-image

Test GitHub Actions

task test-github-actions

Test Release

task release-test

labdoc's People

Contributors

ernail avatar renovate-bot avatar

Stargazers

Moritz (Eilfort) Räpple avatar Pascal Schwahn avatar  avatar Moritz avatar Hannes Ortmeier avatar

Watchers

 avatar

labdoc's Issues

[FEATURE] Add functionality for displaying the version of `labdoc`

Feature Request

Motivation

Right now, there is no simple way to find out which version of labdoc is being used. This could be resolved by adding a --version flag that will display the current version.

Proposed Solution

Add the --version flag and the logic for displaying the version. The version has to be set during the build process. The flag should be added using cobra.

[FEATURE] Support Gitlab CI/CD components that define no specs/no jobs/only includes of other components

Feature Request

Motivation

This feature revolves around multiple topics. What should happen if the component defines no specs? What if it defines no jobs? What if the component only includes other components/templates?

Proposed Solution

Those are just some random thoughts, no final solution:

  • If there are no specs defined, don't document the inputs table. Or give a note that there are no inputs
  • If there are no jobs defined, don't document the jobs, or give a note that there are none.
  • If there are includes, document them. Maybe add a link to them in the docs.

[BUG] Anchor links are not rendered correctly

Bug Report

Describe the bug

When using anchor links in the comments that are used to generate the documentation, the rendered version will not contain the # char, which breaks the link.

For example, if the component has a comment: # This component includes the [foo component](#foo)
It will be rendered as This component includes the [foo component](foo).

Reproducing the bug

Steps to reproduce the behavior:

  1. Create a comment including an anchor link
  2. Generate the documentation
  3. Find the broken link in the documentation

Expected behavior

The link should not be broken in the rendered documentation

Version

1.0.1

Additional Information

The problem lies in the method for formatting a comment for Markdown. The # is removed, but not only in the beginning of the line.

We should adapt the logic and add a new Test for this

[BUG] The order of components is not deterministic

Bug Report

Describe the bug

When having multiple components to be documented, the order in which they are rendered is not deterministic. This will cause the --check to fail, as well as the pre-commit hook.

Reproducing the bug

Steps to reproduce the behavior:

  1. Create 2 components
  2. Generate the documentation multiple times
  3. See the order of components in the documentation changing

Expected behavior

The order of components should not change.

Version

1.0.2

Additional information

An alphabatical sorting of the components should occur.

[FEATURE] Add "Mandatory" boolean column to the inputs table of the generated documentation

Feature Request

Motivation

It's not exactly clear if a value has to be set, or if a default exists. It might make sense to add an extra column for this to the inputs table.

Proposed Solution

Expand the default template with a new column. If a default value exists, it should say No or false. If a default value exists, it should say Yes or true. It is important to differentiate between a default value that is set to an empty string or array, and no default value.

[FEATURE] Add an outputs section to the generated documentation for GitLab CI/CD components

Feature Request

Motivation

Right now, the documentation generated for Gitlab CI/CD components shows only possible inputs.
When jobs use artifacts, it would be useful to document them as outputs as part of the documentation.

Proposed Solution

The artifacts keyword of each job would have to be parsed. In the documentation, the outputs should either be documented next to the inputs, or for each job.

[FEATURE] Support the directory structure where Gitlab CI/CD component files are located in subdirectories of the `templates` directory.

Feature Request

Motivation

At the moment, labdoc expects all Gitlab CI/CD component files to be on the root level of the templates directory. However, Gitlab also provides the possibility to have the templates in subdirectories with template.yml files. For example, templates/secret-detection/template.yml.
labdoc should handle both cases.

Proposed Solution

labdoc would have to check if the templates directory contains subdirectories. If yes, the directory name should be used as component name. The template.yml inside the directory should be parsed as usual. If no, the filename should be used as component name, then parsed as usual.

[BUG] Code blocks are not rendered correctly

Bug Report

Describe the bug

When using markdown code blocks in a comment in the component, the markdown is not rendered correctly. This is because the logic for formatting the comment to markdown removes the spaces in the beginning. So currently the codeblock is rendered with missing spaces/tabs

Reproducing the bug

Steps to reproduce the behavior:

  1. Write a code block with indentation
  2. Run labdoc generate
  3. See the rendered codeblock with missing indentation

Expected behavior

The indentation should be kept when rendering a code block.

Version

1.2.0

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.