Update ble.html
1 file changed
tree: 620134d4e2847ce4933aeb099bfa918f9b9fd739
  1. .editorconfig
  2. .gitignore
  3. .mdlrc
  4. README.md
  5. build.py
  6. custom-theme/
  7. deploy.sh
  8. docs/
  9. extras/
  10. mkdocs.yml
  11. requirements.txt
  12. serve.py
  13. versions/
README.md

The Apache MyNewt site is built using MkDocs.

Setup

Clone the repo:

git clone https://github.com/apache/mynewt-site
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 master branch.
  3. Preview your changes using MkDocs.
  4. Submit a pull request.

Releasing a versioned set of MyNewt documentation

When a release of MyNewt OS and its associated tools occurs, a new version directory should be created to hold all docs pertaining to that release. The documentation in the git master branch of this repository always shows the latest docs under development. The following steps will create a documentation directory for a new release and make it available from the mynewt-site.

Build

  1. Merge pull requests to master on github.
  2. Switch to the master branch.
    • git checkout master
  3. While in master, do git pull --rebase origin master to pull the latest merged changes.
  4. Create a new stanza in mkdocs.yml to reflect the new version. (SKIP THIS STEP IF NOT A NEW RELEASE)
    • and update the latest flag, only one release should be marked latest.
    • and update version to match the new directory name.
  5. Commit this change. (SKIP THIS STEP IF NOT A NEW RELEASE)
  6. Create a new directory in the versions directory to reflect this new version. (SKIP THIS STEP IF NOT A NEW RELEASE)
    • Copy the latest docs directory and mkdocs.yml file into the new version directory
    • Set extra.version to the new version in the copied mkdocs.yml file
    • Create a symbolic link to the customer-theme
  7. Run: ./build.py

Test

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

Deploy

  1. Run: ./deploy.sh build
  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: ./build.py --test-build
  3. Run: ./serve.py
  4. point the link checker at http://localhost:8000/