Merge pull request #259 from cwanda/rtt

Added note on J-Link versions and input char limits.
tree: 73e597f592dea7f0b4eec121cf1f51a97960aa45
  1. .editorconfig
  2. .gitignore
  3. .mdlrc
  6. custom-theme/
  8. docs/
  9. extras/
  10. mkdocs.yml
  11. requirements.txt

The Apache MyNewt site is built using MkDocs.


Clone the repo:

git clone
cd mynewt-site

Optional: it's a very good idea to use a virtualenv:

virtualenv venv
. venv/bin/activate

Install the requirements:

pip install -r requirements.txt

Submitting updates

  1. Fork the repo.
  2. Work on the develop branch.
  3. Preview your changes using MkDocs.
  4. Submit a pull request.

Releasing a versioned set of MyNewt documentation

When a new release of MyNewt OS and its associated tools occurs, the documentation in the git develop branch of this repository should be in sync with the released version. The following steps will create a documentation branch for the release and make it available as the default documentation from the mynewt-site.


  1. Merge pull requests to develop on github.
  2. While in develop, do git pull --rebase origin develop to pull the latest merged changes.
  3. Switch to the master branch.
    • git checkout master
  4. Create a new stanza in mkdocs.yml to reflect the new version.
    • and update the latest flag, only one release should be marked latest.
    • and update version to match the new branch name.
  5. Commit this change.
  6. Create a branch from master to reflect this new version.
  7. Run: ./


  1. Run: ./
  2. Visit http://localhost:8000


  1. Run: ./
  2. This will leave you on the asf-site branch.
  3. Commit & push the changes.

The runtime-bot github user does a build every ~15 minutes and opens a Pull Request against the asf-site branch if there are any changes. It is recommended that the runtime-bot PRs are used to deploy changes to the site instead of PRs from individual contributors. The runtime-bot PRs give us repeatable builds using known versions of the build tools.

Links to Documentation

For the deployed site a version prefix is added to the URL for each mkdocs page. When developing there is no version prefix. If you want to link from a site page to a documentation page you should prefix the URL with /DOCSLINK/ so that the user is taken to the correct location when browsing in production.

Link Checking

  1. Grab a link checking tool like Integrity
  2. Run: ./ --test-build
  3. Run: ./
  4. point the link checker at http://localhost:8000/