Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

There are different ways documentation can be written and published within FINOS.

  1. GitHub and Markdown, probably the simplest and most intuitive approach: every file written in MarkDown format and hosted in GitHub is automatically parsed and visualised by GitHub; the README.md file located at the root of a project directory is parsed in the GitHub project homepage, which is now a well established best practice to guide consumers to get started with a project. Read more on GitHub Readme doc page
  2. GitHub Wiki is a service that is available for every GitHub repository; it can be enabled/disabled via the GitHub repository settings and provides a dedicated Git endpoint that can host Markdown files and generates its web version.
  3. GitHub Pages, to customise the look 'n feel of the page and publish the HTML version of your project docs in a custom domain name (ie myproject.com), yet keeping Markdown as documentation language and GitHub as hosting system; GitHub Pages basically reads HTML and Markdown files from a specific repository folder or branch (configured via GitHub repo settings) onto an HTTP endpoint; for example, all contents in github.com/finos/finos.github.io are rendered out in finos.github.io . Additionally, GitHub Pages can be plugged with different interpreters, which allow to build more complex use cases is a basic example of GitHub Pages, which uses plain HTML (and Javascript) to build the website, but alternative interpreters can be plugged into GitHub Pages, such as:
    1. Docusaurus is the most complete and recommended tool to easily manage project documentation on GitHub; is allows to manage content in MarkDown files, configure navigation and sidebars, manage versioning and is highly customizable using React.
    2. Hugo, an alternative to Docusaurus that generates static HTML using Go Templates and some predefined conventions
    3. Jekyll, a Ruby-based static site generator , that is embedded in GitHub Pages; if the GitHub repository content adheres to Jekyll directory structure, GitHub will automatically parse it accordingly; a FINOS example is https://github.com/fdc3/api/tree/gh-pages ; Jekyll delivers advanced features, such as using it is highly customisable using variablescustom layoutsHTML blocks which can be generated by other build processes (ie redoc-cli) and much more.
    4. Hugo, an alternative to Jekyll written in GoLang; it is not embedded into GitHub Pages, but can be easily integrated with the help of Travis CI, which can run the hugo command on commit and push the resulting HTML code into a GitHub branch; the Travis CI pages deployer is a perfect fit for this need.
  4. Atlassian Confluence can be used for any FINOS Program activity; each program has a dedicated Confluence Space (see the full list), where sub-pages can be created to host activity-specific documentation.

Setting up

Travis CI

Simply create a .travis.yml file in the root folder of the repository and follow Travis documentation, according to the adopted languages.

The following environment variables will be needed, in order to run

GitHub Pages

deployments:GH_TOKEN

  • GH_USERNAME
  • GH_EMAIL
  • You can setup variables the Travis Repository Settings or with the travis CLI.

    Setting up GitHub Pages

    The only setup needed is to tell GitHub where to read the documentation sources from; the suggested option is to use the gh-pages branch, for the following reasons:

    1. Most of the times, documentation must be partially generated (from source code) and sometimes patched before being published; generated content should not live in the same place as source code, to avoid frequent downstream updates to local developers repositories
    2. gh-pages is a branch that is normally used exclusively for this purpose
    3. Travis CI provides the pages deployer that works out of the box

    Using Jekyll

    To start with Jekyll, let's start with few simple steps:

    1. Create a docs/ folder in your repository root folder and move all the project MarkDown documentation there; typically, the existing content in README.md gets moved (or copied) into a docs/index.md.
    2. Create a docs/_config.yml, following Jekyll configuration docs

    The FDC3 API repository uses Jekyll to publish documentation; you can check:

    1. the source docs/ folder
    2. the documentation website - fdc3-api.finos.org

    At this point, you can enable Travis CI to run the command and deploy the generated HTML to the gh-pages branch in a continuous way:

    Code Block
    1. , see below

    Setting up Travis CI

    Simply create a .travis.yml file in the root folder of the repository and follow Travis documentation, according to the adopted languages.

    The following environment variables will be needed, in order to run GitHub Pages deployments:

    1. GH_TOKEN
    2. GH_USERNAME
    3. GH_EMAIL

    You can setup variables the Travis Repository Settings or with the travis CLI.

    Code Block
    title.travis.yml
    # Configure Travis CI integration with Github Pages - https://docs.travis-ci.com/user/deployment/pages/
    deploy:
      provider: pages
      skip_cleanup: true
      github_token: $GH_TOKEN
      name: $GH_USERNAME
      email: $GH_EMAIL
      local_dir: docs
      target_branch: gh-pages
      on:
        branch: master

    Running Jekyll locally

    To run locally a Jekyll website, please follow the steps below.

    Install a Ruby environment

    It is strongly advised to use RVM or RBenv to install Ruby; below are the steps to install RVM on MacOS.

    Code Block
    mkdir -p ~/.rvm/src && cd ~/.rvm/src && rm -rf ./rvm && \
    git clone --depth 1 https://github.com/rvm/rvm.git && \
    cd rvm && ./install
    rvm install 2.5.2
    which bundle #Should return a .rvm sub-path
    which ruby #Should return a .rvm sub-path
    Install gems needed for jekyll
    Code Block
    cd /tmp
    git clone https://github.com/pages-themes/slate
    cd slate
    rm -rf .bundle
    ./script/bootstrap
    gem install jekyll-theme-slate
    gem install jekyll-seo-tag
    gem install jekyll-watch
    Run Jekyll
    Code Block
    cd docs/
    jekyll serve --incremental



    Info
    Info

    In order to automate the build, Travis CI must be configured with a GitHub Personal API (or access) Token, also described below as GIT_TOKEN environment variable.

    Using Hugo

    Follow these 3 simple steps to start working on your Hugo website.

    1. Install Hugo locally
    2. Configure Hugo - this 70 second video tutorial will walk you through these steps
    3. Choose a Hugo template that's best for your needs

    To test that everything is functioning correctly, you can run your website locally using Hugo's server command.

    To test the website static generation, simply run the hugo command from the root project folder; a public folder will be created with all HTML generated content.

    At this point, you can enable Travis CI to run the command and deploy the generated HTML to the gh-pages branch in a continuous way:

    Code Block
    # Install hugo CLI tool
    install: true
    before_install:
    - wget https://github.com/gohugoio/hugo/releases/download/v0.49/hugo_0.49_Linux-64bit.deb
    - sudo dpkg -i hugo*.deb
    - hugo version
    
    # Run hugo CLI tool, updates the docs/ folder
    script: hugo
    
    # Configure Travis CI integration with Github Pages - https://docs.travis-ci.com/user/deployment/pages/
    deploy:
      provider: pages
      skip_cleanup: true
      github_token: $GH_TOKEN
      name: $GH_USERNAME
      email: $GH_EMAIL
      local_dir: public
      target_branch: gh-pages
      on:
        branch: master

    Check https://github.com/gohugoio/hugo/releases to update the URL in the before_install command with the latest version.

    While the Foundation has enjoyed success with Hugo, you could substitute other static website engines and the steps described here would still be directionally accurate.