Site | Status |
---|---|
istio.io | |
preliminary.istio.io | |
archive.istio.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.
To learn how to edit and build this repo's content, please refer to Creating and Editing Pages.
Istio maintains three variations of its public site.
istio.io is the main site, showing documentation for the current release of the product.
archive.istio.io contains snapshots of the documentation for previous releases of the product. This is useful for customers still using these older releases.
preliminary.istio.io contains the actively updated documentation for the next release of the product.
The user can trivially navigate between the different variations of the site using the gear menu in the top right of each page. All three sites are hosted on Netlify.
Documentation changes are primarily committed to the master branch of istio.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 istio.io Netlify project's configuration.
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.
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-1.4).
This process can be taken care of automatically by our infrastructure. If you submit a PR
to the master branch and annotate the PR with the actions/merge-to-release-branch
label,
then as soon as your PR is merged into master, it will be merged into the current release branch.
Here are the steps necessary to create a new documentation version. Let's assume the current version of Istio is 1.3 and you wish to introduce 1.4 which has been under development.
The documentation repo pulls content from the Istio source repos for inclusion in the published site. When the source repos are branched in preparation for a release, a few changes are needed in the documentation repo to track this:
Switch to the master branch of the istio/istio.io repo and make sure everything is up to date.
Edit the file Makefile.core.mk
and change the SOURCE_BRANCH_NAME
variable to the
name of the newly created source branches (in this case release-1.4
).
Edit the file data/args.yml
and set the source_branch_name
field to the name of the newly created source
branches (in this case release-1.4
).
Run make update_all
in order to retrieve the latest material from the source repositories.
Commit the previous edits to your local git repo and push your master branch to GitHub.
The day of a major Istio release, assuming you've previously done the steps from the above section, you need to:
Switch to the master branch of the istio/istio.io repo and make sure everything is up to date.
Edit the file scripts/build_archive_site.sh
and add the new archive version
(in this case release-1.3
) to the TOBUILD
variable.
Edit the file data/versions.yml
. Set the preliminary
field to the next Istio release
(in this case 1.5
) and the main
field to the current release (in this case 1.4
).
Commit the previous edits to your local git repo and push your master branch to GitHub.
Create a new release branch off of master, named as release-major.minor (in this case release-1.4
). There is one
such branch for every release.
Edit the file data/args.yml
. Set the preliminary
field to false
and the the doc_branch_name
field to the name of the release branch (in this case release-1.4
).
Commit the previous edits to your local git repo and push your release branch to GitHub.
Go to the istio.io project on Netlify
Change the branch that is built from the previous release's branch to the new release branch, in this case release-1.4
Select the option to trigger an immediate rebuild and redeployment.
Once deployment is done, browse istio.io and make sure everything looks good.
Go to the Google Custom Search Engine and do the following:
Download the archive.istio.io CSE context file from the Advanced tab.
Add a new FacetItem at the top of the file containing the previous release's version number. In this case, this would be "V1.3".
Upload the updated CSE context file to the site.
In the Setup section, add a new site that covers the previous release's archive directory. In this case, the site URL would be archive.istio.io/v1.3/*. Set the label of this site to the name of the facet item created above (V1.3 in this case).
In the previous release's branch (in this case release-1.3
), edit the file data/args.yml
. Set the
archive
field to true and the archive_date
field to the current date, and the rchive_search_refinement
to the previous release version (in this case V1.3
).
In the previous release's branch (in this case release-1.3
), edit the file config.toml
. Set the
disableAliases
field to false
.
Commit the previous edits to your local git repo and push the previous release's branch to GitHub.
In the archive branch, rebase the branch to have all changes from the current release. In this case,
all changes from the release-1.4
branch.
Commit the previous edits to your local git repo and push the archive branch to GitHub.
Wait a while (~20 minutes) and browse archive.istio.io to make sure everything looks good.
In the master branch, edit the file data/args.yml
. Set the version
and full_version
fields to have the version
of the next Istio release, and previous_version
to be the version of the previous release. In this case, you would set the fields to
"1.5", "1.5.0", and "1.4" respectively.
In the master branch, edit the file data/args.yml
. Set the
source_branch_name
and doc_branch_name
fields to master
.
In the master branch, edit the file Makefile.core.mk
. Set the variable SOURCE_BRANCH_NAKE
to
master
.
Run make update_all
in order to retrieve the latest material from the source repositories.
Commit the previous edits to your local git repo and push the master branch to GitHub.
Wait a while (~5 minutes) and browse preliminary.istio.io to make sure everything looks good.
Creating a new patch release involves modifying a few files:
Create the release note for the release by adding a markdown file in
content/en/news/<YEAR>/1.X.Y/index.md
, where 1.X.Y is the name of the release. This is where
you describe the changes in the release.
Edit the data/args.yml
file and change the full_version
field to the name of the release.
Run make update_ref_docs
to get the latest reference docs.
For the release note file, please look at existing files in the same location for example content and layout.
We have a number of checks in place to ensure a number of invariants are maintained in order to help the site's overall quality. For example, we disallow checking in broken links and we do spell checking. There are some things which are hard to systematically check through automation and instead require a human to review on in a while to ensure everything's doing well.
It's a good idea to run through this list before every major release of the site:
Ensure that references to the Istio repos on GitHub don't hardcode branch names. Search for any uses of /release-1
or /master
throughout all the markdown files and replace those with {{< source_branch_name >}} instead, which produces a version-appropriate
branch name.
Review the .spelling file for words thst shouldn't be in there. Type names in particular tend to creep in here. Type names should
not be in the dictionary and should instead be shown with backticks
. Remove the entries from the dictionary and fix any spell
checking errors that emerge.
Ensure proper capitalization. Document titles need to be fully capitalized (e.g. "This is a Valid Title"), while section headings should use first letter capitalization only (e.g. "This is a valid heading").
Ensure that preformatted text blocks that reference files from the Istio GitHub repos use the @@ syntax to produce links to the content. See here for context.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。