Merge branch 'clean-up-yamllint-warnings-3' into 'master'

Clean up whitespace in Whats New yamls

See merge request gitlab-org/gitlab!81967

data/whats_new/202011230001_13_06.yml

@@ -64,7 +64,7 @@
   published_at: 2020-11-22
   release: 13.6
 - title: Milestone Burnup Charts and historically accurate reporting
-  body:  |
+  body: |
     A milestone or iteration burndown chart helps track completion progress of total scope, but it doesn't provide insight into how the scope changed during the course of the timebox. Neither has it previously retained historical accuracy regarding how much of the initial committed scope of the milestone or iteration was actually completed.
 
     To solve these problems and help teams have better insights into scope creep, milestones and iterations now show a burnup chart that tracks the daily total count and weight of issues added to and completed within a given timebox.

data/whats_new/202101140001_13_08.yml

@@ -80,4 +80,3 @@
   image_url: https://about.gitlab.com/images/home/kubernetes.png
   published_at: 2021-01-22
   release: 13.8
-

data/whats_new/202102180001_13_09.yml

@@ -120,4 +120,3 @@
   image_url: https://about.gitlab.com/images/13_9/deploy_keys.png
   published_at: 2021-02-22
   release: 13.9
-

data/whats_new/202103220001_13_10.yml

@@ -5,8 +5,8 @@
   self-managed: true
   gitlab-com: true
   packages: [Free, Premium, Ultimate]
-  url:  https://docs.gitlab.com/runner/install/openshift.html
-  image_url:  https://img.youtube.com/vi/ZNBc_QnDUu4/hqdefault.jpg
+  url: https://docs.gitlab.com/runner/install/openshift.html
+  image_url: https://img.youtube.com/vi/ZNBc_QnDUu4/hqdefault.jpg
   published_at: 2021-03-22
   release: 13.10
 - title: "View epics on a board (MVC)"
@@ -21,7 +21,7 @@
   gitlab-com: true
   packages: [Premium, Ultimate]
   url: https://docs.gitlab.com/ee/user/group/epics/epic_boards.html
-  image_url:  https://about.gitlab.com/images/13_10/view-epics-on-a-board-mvc-1.png
+  image_url: https://about.gitlab.com/images/13_10/view-epics-on-a-board-mvc-1.png
   published_at: 2021-03-22
   release: 13.10
 - title: "View Jira issue details in GitLab"
@@ -35,8 +35,8 @@
   self-managed: true
   gitlab-com: true
   packages: [Premium, Ultimate]
-  url:  https://docs.gitlab.com/ee/user/project/integrations/jira.html#view-a-jira-issue
-  image_url:  https://about.gitlab.com/images/13_10/jira-detail-view.png
+  url: https://docs.gitlab.com/ee/user/project/integrations/jira.html#view-a-jira-issue
+  image_url: https://about.gitlab.com/images/13_10/jira-detail-view.png
   published_at: 2021-03-22
   release: 13.10
 - title: "DORA4-based lead time for changes"
@@ -46,8 +46,8 @@
   self-managed: true
   gitlab-com: true
   packages: [Ultimate]
-  url:  https://docs.gitlab.com/ee/api/dora4_project_analytics.html#list-project-merge-request-lead-times
-  image_url:  https://about.gitlab.com/images/13_10/api.png
+  url: https://docs.gitlab.com/ee/api/dora4_project_analytics.html#list-project-merge-request-lead-times
+  image_url: https://about.gitlab.com/images/13_10/api.png
   published_at: 2021-03-22
   release: 13.10
 - title: "Create a release from an existing tag"
@@ -57,8 +57,8 @@
   self-managed: true
   gitlab-com: true
   packages: [Free, Premium, Ultimate]
-  url:  https://docs.gitlab.com/ee/user/project/releases/#create-a-release
-  image_url:  https://about.gitlab.com/images/13_10/exiting_tags.png
+  url: https://docs.gitlab.com/ee/user/project/releases/#create-a-release
+  image_url: https://about.gitlab.com/images/13_10/exiting_tags.png
   published_at: 2021-03-22
   release: 13.10
 - title: "Integrate any IT alerting tool with GitLab"
@@ -70,8 +70,8 @@
   self-managed: true
   gitlab-com: true
   packages: [Premium, Ultimate]
-  url:  https://docs.gitlab.com/ee/operations/incident_management/integrations.html#http-endpoints
-  image_url:  https://about.gitlab.com/images/13_10/integrate_alerts.png
+  url: https://docs.gitlab.com/ee/operations/incident_management/integrations.html#http-endpoints
+  image_url: https://about.gitlab.com/images/13_10/integrate_alerts.png
   published_at: 2021-03-22
   release: 13.10
 - title: "Merge request test summary usability improvements"
@@ -85,7 +85,7 @@
   self-managed: true
   gitlab-com: true
   packages: [Free, Premium, Ultimate]
-  url:  https://docs.gitlab.com/ee/ci/unit_test_reports.html
-  image_url:  https://about.gitlab.com/images/13_10/test_summary_ux_improvements.png
+  url: https://docs.gitlab.com/ee/ci/unit_test_reports.html
+  image_url: https://about.gitlab.com/images/13_10/test_summary_ux_improvements.png
   published_at: 2021-03-22
   release: 13.10

data/whats_new/202104220001_13_11.yml

@@ -38,7 +38,7 @@
   gitlab-com: true
   packages: [Premium, Ultimate]
   url: https://docs.gitlab.com/ee/operations/incident_management/oncall_schedules.html
-  image_url:  https://img.youtube.com/vi/QXfCQ24-Ufo/hqdefault.jpg
+  image_url: https://img.youtube.com/vi/QXfCQ24-Ufo/hqdefault.jpg
   published_at: 2021-04-22
   release: 13.11
 - title: Use multiple caches in the same job
@@ -49,21 +49,21 @@
   gitlab-com: true
   packages: [Free, Premium, Ultimate]
   url: https://docs.gitlab.com/ee/ci/yaml/index.html#multiple-caches
-  image_url:  https://about.gitlab.com/images/13_11/cache.png
+  image_url: https://about.gitlab.com/images/13_11/cache.png
   published_at: 2021-04-22
   release: 13.11
-- title:  Group SAML Enforcement for Git activity
+- title: Group SAML Enforcement for Git activity
   body: |
     GitLab group maintainers can now enhance their group security by enforcing Group SAML for Git activity. Security-minded organizations want all GitLab activity to be protected and governed by their SAML Identity Provider. Currently, SAML SSO enforcement only applies to activity in the GitLab UI. Git CLI operations do not require an active SAML SSO session. When Git Group SAML SSO enforcement is enabled, users must have an active web SAML session to perform Git operations in the CLI.
   stage: Manage
   self-managed: false
   gitlab-com: true
-  packages:  [Premium, Ultimate]
+  packages: [Premium, Ultimate]
   url: https://docs.gitlab.com/ee/user/group/saml_sso/#sso-enforcement
   image_url: https://about.gitlab.com/images/sdlc-icons/manage.svg
   published_at: 2021-04-22
   release: 13.11
-- title:  Cherry pick commits from fork to parent
+- title: Cherry pick commits from fork to parent
   body: |
     With GitLab 13.11, if you are a project member, you can now cherry-pick commits from downstream forks back into your project. We've added a new **Pick into project** section to the cherry-pick dialog, shown when you select **Options > Cherry-pick** on a commit's details page.
 
@@ -73,9 +73,9 @@
   stage: Create
   self-managed: true
   gitlab-com: true
-  packages:  [Free, Premium, Ultimate]
+  packages: [Free, Premium, Ultimate]
   url: https://docs.gitlab.com/ee/user/project/merge_requests/cherry_pick_changes.html#cherry-pick-into-a-project
-  image_url:  https://about.gitlab.com/images/13_11/cherry_pick_commits_from_fork_to_parent.png
+  image_url: https://about.gitlab.com/images/13_11/cherry_pick_commits_from_fork_to_parent.png
   published_at: 2021-04-22
   release: 13.11
 - title: Improvements to Jira Connect application configuration
@@ -104,7 +104,7 @@
   image_url: https://about.gitlab.com/images/13_11/search-settings.gif
   published_at: 2021-04-22
   release: 13.11
-- title:  Deploy GitLab on OpenShift and Kubernetes with the GitLab Operator (beta)
+- title: Deploy GitLab on OpenShift and Kubernetes with the GitLab Operator (beta)
   body: |
     GitLab is working to offer full support for OpenShift. To accomplish this, we have released the MVP [GitLab Operator](https://gitlab.com/gitlab-org/gl-openshift/gitlab-operator/-/tree/master/doc). The operator aims to manage the full lifecycle of GitLab instances on Kubernetes and OpenShift container platforms. Currently, this is a [beta release](https://gitlab.com/groups/gitlab-org/-/epics/3444) and it is **not recommended for production use**. The next steps will be to make the operator generally available (GA). In the future the operator will become the recommended installation method for Kubernetes and OpenShift, although the GitLab Helm chart will still be supported. We welcome you to try this operator and [provide feedback on our issue tracker](https://gitlab.com/gitlab-org/gl-openshift/gitlab-operator/-/issues/131).
   stage: Enablement
@@ -112,6 +112,6 @@
   gitlab-com: true
   packages: [Free, Premium, Ultimate]
   url: https://gitlab.com/gitlab-org/gl-openshift/gitlab-operator/-/tree/master/doc
-  image_url:  https://about.gitlab.com/images/13_11/gitlab-operator.png
+  image_url: https://about.gitlab.com/images/13_11/gitlab-operator.png
   published_at: 2021-04-22
   release: 13.11

data/whats_new/202106220001_14_0.yml

@@ -149,7 +149,7 @@
 - title: Terraform module registry built into GitLab
   body: |
     Terraform modules play a central role in building standard infrastructure components throughout an organization. Up to GitLab 13.12, GitLab users had to use either a third-party Terraform module registry, local modules, or Git-based modules. While these options work well, they do not help with the distribution of the modules and they lack proper versioning support, which introduces risks for module users. GitLab 14.0 extends our [Infrastructure-as-Code offerings](https://docs.gitlab.com/ee/user/infrastructure/) with a Terraform module registry. Now, you can use the Terraform module registry built into GitLab to discover Terraform modules with semantic versioning support for upgrades and maintenance. Moreover, you can publish modules easily using GitLab CI/CD.
-    
+
     While following Terraform's best practices, we recommend developing each Terraform module in a dedicated GitLab project. To simplify the transition to the registry, users can host and publish multiple modules from a single GitLab repository. You can learn more about publishing and consuming a new module [in our documentation](https://docs.gitlab.com/ee/user/packages/terraform_module_registry/index.html).
   stage: Configure
   self-managed: true

data/whats_new/202107220001_14_1.yml

@@ -27,7 +27,7 @@
 
    With [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) [v3.26.0](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md#3260-2021-07-13) for VS Code you can now create and apply patches directly in your editor. The new `GitLab: Create snippet patch` command creates a patch with the changes in your editor and uploads that patch as a [GitLab snippet](https://docs.gitlab.com/ee/user/snippets.html).
 
-   Anyone can search for patches in the project's snippets and apply them directly in VS Code with the `GitLab: Apply snippet patch` command. The applied changes can then be committed to the MR.    
+   Anyone can search for patches in the project's snippets and apply them directly in VS Code with the `GitLab: Apply snippet patch` command. The applied changes can then be committed to the MR.
 
    Sharing and collaborating around patches is a great way to propose more complex suggestions and provide clear improvements. Patches created in VS Code can also be linked to others through snippets and downloaded and applied outside of VS Code for users with different editing tools.
   stage: Create
@@ -38,7 +38,7 @@
   image_url: https://img.youtube.com/vi/QQxpLoKJULQ/hqdefault.jpg
   published_at: 2021-07-22
   release: 14.1
-- title: Code coverage merge request approval rule 
+- title: Code coverage merge request approval rule
   body: |
    To keep code test coverage high, you need to ensure that merge requests to your codebase never decrease test coverage. Previously, the only way to enforce this was to [require approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/#required-approvals) from users who would check for test coverage decreases as part of their reviews.
 
@@ -68,7 +68,7 @@
 
    GitLab already supports a variety of other [package manager formats](https://docs.gitlab.com/ee/user/packages/). Why not also support Helm? That's what community member and [MVP from the 14.0 milestone](https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-released/#mvp) [Mathieu Parent](https://gitlab.com/sathieu) asked several months ago before breaking ground on the new GitLab Helm chart registry. The collaboration between the community and GitLab is part of our [dual flywheel strategy](https://about.gitlab.com/company/strategy/#dual-flywheels) and one of the reasons we love working at GitLab. Chapeau Mathieu!
 
-   Now you can use your GitLab project to publish and share packaged Helm charts. Simply add your project as a remote, authenticating with a personal access, deploy, or CI/CD job token. Once that's done you can use the Helm client or GitLab CI/CD to manage your Helm charts. You can also download the charts using the [API](https://docs.gitlab.com/ee/api/packages.html#get-a-project-package) or the [user interface](https://docs.gitlab.com/ee/user/packages/package_registry/#download-a-package). 
+   Now you can use your GitLab project to publish and share packaged Helm charts. Simply add your project as a remote, authenticating with a personal access, deploy, or CI/CD job token. Once that's done you can use the Helm client or GitLab CI/CD to manage your Helm charts. You can also download the charts using the [API](https://docs.gitlab.com/ee/api/packages.html#get-a-project-package) or the [user interface](https://docs.gitlab.com/ee/user/packages/package_registry/#download-a-package).
   stage: Package
   self-managed: true
   gitlab-com: true
@@ -81,7 +81,7 @@
   body: |
    Being on-call is a stressful, 24/7 job. It's possible to miss a notification despite your best efforts and intentions. Teams that maintain critical systems can't afford to miss alerts for outages or service disruptions. Escalation policies are a safety net for these situations. Escalation policies contain time-boxed steps that automatically page a responder in the next escalation step if the responder in the step before didn't respond. To protect your company from missed critical alerts, create an escalation policy in the GitLab project where you manage on-call schedules.
 
-   In GitLab 14.1, users can create, view, or delete escalation policies. 
+   In GitLab 14.1, users can create, view, or delete escalation policies.
   stage: Monitor
   self-managed: true
   gitlab-com: true
@@ -128,7 +128,7 @@
   release: 14.1
 - title: Pronouns viewable in user profile snapshot
   body: |
-   You can now see pronouns on the snapshot view of a user profile when you hover over someone's name on an issue or merge request. This helps users better respond to comments using the correct pronouns without needing to navigate to the user's profile. 
+   You can now see pronouns on the snapshot view of a user profile when you hover over someone's name on an issue or merge request. This helps users better respond to comments using the correct pronouns without needing to navigate to the user's profile.
   stage: Manage
   self-managed: true
   gitlab-com: true

data/whats_new/2021102000001_14_04.yml

@@ -13,7 +13,7 @@
   body: |
       When working in your editor you may need to refer to another project or upstream library for additional information. When you don't have that project already cloned locally, you're forced to either leave your editor and browse the project on GitLab, or locate and then clone the project so you can browse it in your editor. Both of those tasks break your current context, introduce delays, and can take you to a less familiar interface for working with code.
 
-      [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) version `3.33.0` provides an option to open a remote repository. Open the command palette and use the `GitLab: Open Remote Repository` command to find and then open a project. 
+      [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) version `3.33.0` provides an option to open a remote repository. Open the command palette and use the `GitLab: Open Remote Repository` command to find and then open a project.
 
       Opening a remote repository allows you to browse a read-only version of a project in your familiar VS Code environment. You can then quickly find the information you're looking for, compare an implementation, or copy a snippet you need.
   stage: Create
@@ -57,4 +57,3 @@
   image_url: https://about.gitlab.com/images/14_4/monitor-integrated-error-tracking.png
   published_at: 2021-10-22
   release: 14.4
-

data/whats_new/202112200001_14_06.yml

@@ -33,9 +33,9 @@
   release: 14.6
 - title: Toggle wiki editors seamlessly
   body: |
-     Editing wiki pages with the new rich Markdown editor makes it easier for everyone to contribute regardless of how well they know Markdown syntax. You may also prefer to write raw Markdown in some situations, but use the WYSIWYG interface for more complex or tedious formatting tasks, like creating tables. 
+     Editing wiki pages with the new rich Markdown editor makes it easier for everyone to contribute regardless of how well they know Markdown syntax. You may also prefer to write raw Markdown in some situations, but use the WYSIWYG interface for more complex or tedious formatting tasks, like creating tables.
 
-      Previous versions of GitLab required you to save changes before switching between the rich Markdown editor and the Markdown source, adding more steps and friction to your edits. In GitLab 14.6 you can now seamlessly switch between the two editing experiences without committing your changes, choosing the editor that suits your needs at any given moment. 
+      Previous versions of GitLab required you to save changes before switching between the rich Markdown editor and the Markdown source, adding more steps and friction to your edits. In GitLab 14.6 you can now seamlessly switch between the two editing experiences without committing your changes, choosing the editor that suits your needs at any given moment.
   stage: Create
   self-managed: true
   gitlab-com: true

data/whats_new/202201200001_14_07.yml

@@ -39,4 +39,3 @@
   image_url: https://about.gitlab.com/images/14_7/group_access_token.png
   published_at: 2022-01-22
   release: 14.7
-

data/whats_new/202202210001_14_08.yml

@@ -31,7 +31,7 @@
     - Multiple rules can be created and chained together to allow for filtering on different severity thresholds for each scanner type.
     - A two-step approval process can be enforced for any desired changes to security approval rules.
     - A single set of security policies can be applied to multiple development projects to allow for ease in maintaining a single, centralized ruleset.
-    
+
     Security approval policies can be used alongside the existing Vulnerability-Check feature, as the two policies are additive and don't conflict. However, we encourage users to migrate their Vulnerability-Check rules over to security approval policies. Vulnerability-Check rules are now [deprecated](https://docs.gitlab.com/ee/update/deprecations.html#vulnerability-check), and are scheduled for removal in GitLab 15.0. Self managed users will need to enable the `scan_result_policy` feature flag prior to using this feature. To get started, navigate to **Security & Compliance > Policies** and create a new Scan Result type policy.
   stage: protect
   self-managed: true
@@ -58,7 +58,7 @@
     [user impersonation](https://docs.gitlab.com/ee/user/admin_area/#user-impersonation) starting and stopping. This was previously
     only available on a page unavailable to GitLab SaaS customers. We are excited to bring
     it to the group page which allows both self-managed and SaaS users to view these events!
-    
+
     These events are helpful to understand if an administrator impersonated a user in your group and any actions that the
     administrator took as the impersonated user. You can correlate:
 
@@ -80,7 +80,7 @@
   body: |
     In this release, we have introduced additional progress tracking capabilities to roadmaps. You can now view the percentage of completed epics based on issue count instead of issue weight. This functionality is useful for organizations that are using Kanban or other methodologies that don't require their teams to set a weight on issues.
 
-    You can now also customize the level of milestones to include in your roadmap, allowing you to tailor your view to meet the needs of your audience.    
+    You can now also customize the level of milestones to include in your roadmap, allowing you to tailor your view to meet the needs of your audience.
   stage: plan
   self-managed: true
   gitlab-com: true
@@ -89,4 +89,3 @@
   image_url: 'https://about.gitlab.com/images/14_8/rp_roadmap_settings.png'
   published_at: 2022-02-22
   release: 14.8
-  
\ No newline at end of file

data/whats_new/templates/YYYYMMDD0001_XX_YY.yml

@@ -9,8 +9,8 @@
 #
 # Please delete this line and above before submitting your merge request.
 
-- title: # Match the release post entry
-  body: | # Do not modify this line, instead modify the lines below.
+- title:  # Match the release post entry
+  body: |  # Do not modify this line, instead modify the lines below.
     <!-- START OF BODY COMMENT
 
     This area supports markdown.
@@ -22,11 +22,11 @@
     Delete this entire comment and replace it with your markdown content.
 
     END OF BODY COMMENT -->
-  stage: # String value of the stage that the feature was created in. e.g., Growth
-  self-managed: # Boolean value (true or false)
-  gitlab-com: # Boolean value (true or false)
-  packages: # Array of strings. The Array brackets are required here. e.g., [Core, Starter, Premium, Ultimate]
-  url: # This is the documentation URL, but can be a URL to a video if there is one
-  image_url: # This should be a full URL, generally taken from the release post content. If a video, use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
-  published_at: # YYYY-MM-DD
-  release: # XX.Y
+  stage:  # String value of the stage that the feature was created in. e.g., Growth
+  self-managed:  # Boolean value (true or false)
+  gitlab-com:  # Boolean value (true or false)
+  packages:  # Array of strings. The Array brackets are required here. e.g., [Core, Starter, Premium, Ultimate]
+  url:  # This is the documentation URL, but can be a URL to a video if there is one
+  image_url:  # This should be a full URL, generally taken from the release post content. If a video, use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
+  published_at:  # YYYY-MM-DD
+  release:  # XX.Y