Helm chart install page: start structural revisions
What does this MR do?
Now that !5030 (merged) is merged, let's start moving the subheadings into a more logical order. This MR modifies:
- Move
## Configuring GitLab Runner using the Helm Chart
above theInstall
subheading, as it's essentially a long and complex prerequisite - Handle subheadings of
## Configuring GitLab Runner using the Helm Chart
:- blend child subheading
### Required configuration
(child) back into it - move child subheading
### Additional configuration
from H3 to H2, and bump those to the bottom of the page to get a cleaner flow through the major CRUD steps - because
Additional configuration
changed a H2, update the heading levels for the subheadings underneath
- blend child subheading
- Move
## Check available GitLab Runner Helm Chart versions
from an H2 further down the page, to a H3 nested underneathInstalling
, because theInstalling
subheading ends with a description of selecting a chart version. - Move
## Uninstalling GitLab Runner using the Helm Chart
above all the additional configuration options, to keep the major parts of CRUD together.
Related issues
- Follow-up to Address line-level findings in Kubernetes insta... (!5030 - merged)
- Related to technical-writing#1075
Author's checklist
-
Optional. Consider taking the GitLab Technical Writing Fundamentals course. -
Follow the: -
If you're adding or changing the main heading of the page (H1), ensure that the product tier badge is added. -
If you are a GitLab team member, request a review based on: - The documentation page's metadata.
- The associated Technical Writer.
If you are a GitLab team member and only adding documentation, do not add any of the following labels:
~"frontend"
~"backend"
~"type::bug"
~"database"
These labels cause the MR to be added to code verification QA issues.
Reviewer's checklist
Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.
If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.
-
If the content requires it, ensure the information is reviewed by a subject matter expert. - Technical writer review items:
-
Ensure docs metadata is present and up-to-date. -
Ensure the appropriate labels are added to this MR. -
Ensure a release milestone is set. - If relevant to this MR, ensure content topic type principles are in use, including:
-
The headings should be something you'd do a Google search for. Instead of Default behavior
, say something likeDefault behavior when you close an issue
. -
The headings (other than the page title) should be active. Instead of Configuring GDK
, say something likeConfigure GDK
. -
Any task steps should be written as a numbered list. - If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
-
-
-
Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review.
Merge request reports
Activity
changed milestone to %17.5
assigned to @aqualls
added sectionci label
Reviewer roulette
Changes that require review have been detected! A merge request is normally reviewed by both a reviewer and a maintainer in its primary category and by a maintainer in all other categories.
To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.
Once you've decided who will review this merge request, mention them as you normally would! Danger does not automatically notify them for you.
Reviewer Maintainer @josephburnett
(UTC-7, same timezone as author)
@avonbertoldi
(UTC-6, 1 hour ahead of author)
If needed, you can retry the
danger-review
job that generated this comment.Generated by
DangerEdited by ****added docs-only label
removed docs-only label
added docs-only label
- Resolved by Suzanne Selhorn
@sselhorn Here's where we start diving into the structure on the Helm chart install page. In short, I tried to get the four basic instructions (configure, install, update, uninstall) together at the top of the page, while shifting the collection of somewhat-random extra config options further down.
(I don't yet have answers on how to group those config options into buckets, and this MR has gone far enough already.)
Review app: https://main-runner-5038.docs.gitlab-review.app/runner/install/kubernetes.html
requested review from @sselhorn
@aqualls LGTM, merging. Two things for your next MR:
- Capitalization of "Helm chart"
- Maybe split the page? Top page to have: install, upgrade, uninstall. Separate page to have "configuration" and all the random stuff? (Unless you can split the random stuff even further...)
added this merge request to the merge train at position 2
mentioned in commit 47af9bd0
mentioned in merge request !5054 (merged)
mentioned in merge request jointeg/infrastructure/compose-services!113 (merged)