Skip to content

Latest commit

 

History

History
174 lines (119 loc) · 7.52 KB

README.md

File metadata and controls

174 lines (119 loc) · 7.52 KB
Raw

istio.github.io

This repository contains the source code for the istio.io, preliminary.istio.io and archive.istio.io sites.

Please see the main Istio README file to learn about the overall Istio project and how to get in touch with us. To learn how you can contribute to any of the Istio components, please see the Istio contribution guidelines.

Working with the site

We use Jekyll to generate our sites.

To run the site locally with Docker, use the following command from the top level directory for this git repo (e.g. pwd must be ~/github/istio.github.io if you were in ~/github when you issued git clone https://github.com/istio/istio.github.io.git)

# First time: (slow)
docker run --name istio-jekyll --volume=$(pwd):/srv/jekyll -w /srv/jekyll -it -p 4000:4000 jekyll/jekyll:3.7.3 sh -c "bundle install && rake test && bundle exec jekyll serve --incremental --host 0.0.0.0"
# Then open browser with url 127.0.0.1:4000 to see the change.
# Subsequent, each time you want to see a new change and you stopped the previous run by ctrl+c: (much faster)
docker start istio-jekyll -a -i
# Clean up, only needed if you won't be previewing website changes for a long time or you want to start over:
docker rm istio-jekyll

The rake test part is to make sure you are not introducing HTML errors or bad links, you should see

HTML-Proofer finished successfully.

in the output.

Alternatively, if you just want to develop locally w/o Docker/Kubernetes/Minikube, you can try installing Jekyll locally. You may need to install other prerequisites manually (which is where using the docker image shines). Here's an example of doing so for Mac OS X:

xcode-select --install
sudo xcodebuild -license
brew install ruby
gem update --system
gem install mdspell
gem install bundler
gem install jekyll
cd istio.github.io
bundle install
bundle exec rake test
bundle exec jekyll serve

Linting

You should run scripts/linters.sh prior to checking in your changes. This will run 3 tests:

  • HTML proofing, which ensures all your links are valid along with other checks.

  • Spell checking.

  • Style checking, which makes sure your markdown file complies with some common style rules.

If you get a spelling error, you have three choices to address it:

  • It's a real typo, so fix your markdown.

  • It's a command/field/symbol name, so stick some backticks around it.

  • It's really valid, so go add the word to the .spelling file at the root of the repo.

Versions and releases

Istio maintains three variations of its public site:

  • istio.io is the main site, showing documentation for the current release of the product. This site is currently hosted on Firebase.

  • archive.istio.io contains snapshots of the documentation for previous releases of the product. This is useful for customers still using these older releases. This site is currently hosted on Firebase.

  • preliminary.istio.io contains the actively updated documentation for the next release of the product. This site is hosted by GitHub Pages.

The user can trivially navigate between the different variations of the site using the gear menu in the top right of each page.

How versioning works

  • Documentation changes are primarily committed to the master branch of istio.github.io. Changes committed to this branch are automatically reflected on preliminary.istio.io.

  • The content of istio.io is taken from the latest release-XXX branch. The specific branch that is used is determined by the BRANCH variable in this script

  • The content of archive.istio.io is taken from the older release-XXX branches. The set of branches that are included on archive.istio.io is determined by the TOBUILD variable in this script

The above means that if you want to do a change to the main istio.io site, you will need to make the change in the master branch of istio.github.io and then merge that change into the release branch.

Publishing content immediately

Checking in updates to the master branch will automatically update preliminary.istio.io, and will only be reflected on istio.io the next time a release is created, which can be several weeks in the future. If you'd like some changes to be immediately reflected on istio.io, you need to check your changes both to the master branch and to the current release branch (named release-XXX such as release-0.7).

Creating a version

Here are the steps necessary to create a new documentation version. Let's assume the current version of Istio is 0.6 and you wish to introduce 0.7 which has been under development.

  1. Create a new release branch off of master, named as release-major.minor, which in this case would be release-0.7. There is one such branch for every release.

  2. In the master branch, edit the file _data/istio.yml and update the version field to have the version of the next release of Istio. In this case, you would set the field to 0.8.

  3. In the master branch, edit the file _data/releases.yml and add a new entry at the top of the file for version 0.8. You'll need to make sure the URLs are updated for the first few entries. The top entry (0.8) should point to preliminary.istio.io. The second entry (0.7) should point to istio.io. The third and subsequent entries should point to archive.istio.io.

  4. Commit the previous two edits to GitHub.

  5. In the release branch you created, edit the file _data/istio.yml. Set the preliminary field to false.

  6. Commit the previous edit to GitHub.

  7. Go to the Google Search Console and create a new search engine that searches the archive.istio.io/V<major>.<minor> directory. This search engine will be used to perform version-specific searches on archive.istio.io.

  8. In the previous release's branch (in this case release-0.6), edit the file _data/istio.yml. Set the archive field to true, the archive_date field to the current date, and the search_engine_id field to the ID of the search engine you created in the prior step.

  9. Switch to the istio/admin-sites repo.

  10. Navigate to the archive.istio.io directory.

  11. Edit the build.sh script to add the newest archive version (in this case release-0.6) to the TOBUILD variable.

  12. Commit the previous edit to GitHub.

  13. Run the build.sh script.

  14. Once the script completes, run firebase deploy. This will update archive.istio.io to contain the right set of archives, based on the above steps.

  15. Navigate to the current.istio.io directory.

  16. Edit the build.sh script to set the BRANCH variable to the current release branch (in this case release-0.7)

  17. Run the build.sh script.

  18. Once the script completes, run 'firebase deploy`. This will update the content of istio.io to reflect what is the new release branch you created.

Once all this is done, browse the three sites (preliminary.istio.io, istio.io, and archive.istio.io) to make sure everything looks good.