Closes#14578
The Jira Cloud guide applies to all Jira deployments already, so we
don't need to maintain separate guides. This change renames the Jira
Cloud guide so it's about Jira in general.
* Organize docs guide sections chronologically
This change aims to make docs navigation easier by organizing some docs
sections according to the sequence of steps a user would take to set up
Teleport.
The current docs organization uses a variety of categories and schemes
to organize the docs. For example, there is a "Home" section that
includes the Changelog, Installation page, and Getting Started guides; a
"Setup" section that includes references and admin guides; and
edition-specific sections (Enterprise, Cloud). For a user who is setting
up Teleport--or who has already done some setup work and wants more
advanced instructions--it's difficult to know where in the docs to find
the right information.
This change organizes our how-to guides into the following categories
that describe the process of setting up Teleport:
- Try out Teleport
- Deploy a Cluster (including choosing an edition)
- Configure Access (including SSO, RBAC, and Access Requests)
- Manage your Cluster (admin guides, operations, etc.)
- Use Teleport (this section already exists)
I moved the Reference section after this chronology, since users can
access the reference guides anywhere in the setup process.
As part of the change, I have also moved the content from the
"Enterprise" and "Cloud" sections into "Deploy a Cluster", since this
content has to do with how to deploy a specific edition of Teleport.
Note that this change does _not_ attempt to reorganize our
protocol-specific sections. While adding resources is part of the
Teleport setup process, we have a lot of content in our
protocol-specific sections, and moving it all into a single section
related to adding resources to a cluster would (a) exceed the maximum
depth for subsections in the nav bar and (b) cause more confusion than
it alleviates.
* Respond to PR feedback
- Create a "Compliance Frameworks" section of "Configure Access" with
the FedRAMP and SOC 2 guides
- Rename "Use Teleport" to "Connect your Client"
- Move the database GUI client guide into "Connect your Client"
* Add redirects
* Fix linter issues
Reorganize our Access Request guides
Fixes#13696
Most guides to Access Requests are currently not listed on the sidebar,
and the guides that are listed are available for Cloud as well as
Enterprise. This change makes it easier to find our Access Requests
guides by moving them to the Access Controls section and listing all
guides on the sidebar. It adds the "Access Requests" and "Access Request
Plugins" subsections to "Access Controls".
Since the Access Controls section includes one subsection, called
"Guides", this change also renames that subsection--and adds a
descriptive intro paragraph to the section's menu page--in order to
accommodate the Access Requests and Access Request Plugins subsections.
Move some guides into "Access Requests"
Updates the image used to run the doc-tests CI build and pulls in changes from #13774 to fix compatibility issues with the new image.
See-Also: #13457
Co-authored-by: Paul Gottschling <paul.gottschling@goteleport.com>
The linting applied to file via the tools in next appears to vary if the files are outside the /src directory: If the files are under /src, a rigorous lint is applied. If the files are outside of /src, a "less-rigorous" lint is applied, letting many legitimate issues slip through.
This patch alters the CI script to symlink the /workspace directory (the mount-point that GCB uses to inject code into the container running a build step) under the next image's /src/content directory, so that the correct, rigorous lint will be applied.
It also fixes the lint errors that have crept in during the time the linter was being incorrectly lenient.
See-Also: #9600
See-Also: #10107
With this change `tsh login` will still always add teleport contexts and credentials to the kubeconfig, but will only update the current context if:
- `tsh login` is called with `--kube-cluster` set, or
- `tsh kube login <kube cluster>` is called.
