Merge branch 'jswain_whats_new_markdown' into 'master'

Add markdown support for "whats new"

See merge request gitlab-org/gitlab!48274

app/assets/javascripts/whats_new/components/feature.vue

 <script>
-import { GlBadge, GlIcon, GlLink } from '@gitlab/ui';
+import { GlBadge, GlIcon, GlLink, GlSafeHtmlDirective } from '@gitlab/ui';
 
 export default {
   components: {
@@ -7,6 +7,9 @@ export default {
     GlIcon,
     GlLink,
   },
+  directives: {
+    SafeHtml: GlSafeHtmlDirective,
+  },
   props: {
     feature: {
       type: Object,
@@ -51,7 +54,7 @@ export default {
         class="img-thumbnail gl-px-8 gl-py-3 whats-new-item-image"
       />
     </gl-link>
-    <p class="gl-pt-3">{{ feature.body }}</p>
+    <div v-safe-html="feature.body" class="gl-pt-3"></div>
     <gl-link
       :href="feature.url"
       target="_blank"

app/models/release_highlight.rb

@@ -34,11 +34,23 @@ class ReleaseHighlight
     return if file_path.nil?
 
     file = File.read(file_path)
-
     items = YAML.safe_load(file, permitted_classes: [Date])
 
     platform = Gitlab.com? ? 'gitlab-com' : 'self-managed'
-    items&.select {|item| item[platform] }
+
+    items&.map! do |item|
+      next unless item[platform]
+
+      begin
+        item.tap {|i| i['body'] = Kramdown::Document.new(i['body']).to_html }
+      rescue => e
+        Gitlab::ErrorTracking.track_exception(e, file_path: file_path)
+
+        next
+      end
+    end
+
+    items&.compact
   rescue Psych::Exception => e
     Gitlab::ErrorTracking.track_exception(e, file_path: file_path)
 

data/whats_new/202008180001_12_10.yml

 ---
 - title: Create and view requirements in GitLab
-  body: The first step towards managing requirements from within GitLab is here! This initial release allows users to create and view requirements at a project level. As Requirements Management evolves in GitLab, stay tuned for support for traceability between all artifacts, creating a seamless workflow to visually demonstrate completeness and compliance.
+  body: |
+    The first step towards managing requirements from within GitLab is here! This initial release allows users to create and view requirements at a project level.
+
+    As Requirements Management evolves in GitLab, stay tuned for support for traceability between all artifacts, creating a seamless workflow to visually demonstrate completeness and compliance.
   stage: Plan
   self-managed: true
   gitlab-com: true
   packages: [Ultimate, Gold]
   url: https://docs.gitlab.com/ee/user/project/requirements/index.html
-  image_url:
+  image_url: https://docs.gitlab.com/ee/user/project/requirements/img/requirements_list_v13_5.png
   published_at: 2020-04-22
   release: 12.10
 - title: Retrieve CI/CD secrets from HashiCorp Vault
-  body: In this release, GitLab adds support for lightweight JSON Web Token (JWT) authentication to integrate with your existing HashiCorp Vault. Now, you can seamlessly provide secrets to CI/CD jobs by taking advantage of HashiCorp's JWT authentication method  rather than manually having to provide secrets as a variable in GitLab.
+  body: |
+    In this release, GitLab adds support for lightweight JSON Web Token (JWT) authentication to integrate with your existing HashiCorp Vault.
+
+    Now, you can seamlessly provide secrets to CI/CD jobs by taking advantage of [HashiCorp's JWT authentication method](https://www.vaultproject.io/docs/auth/jwt) rather than manually having to provide secrets as a variable in GitLab.
   stage: Release
   self-managed: true
   gitlab-com: true
@@ -20,7 +26,12 @@
   published_at: 2020-04-22
   release: 12.10
 - title: Epic and Issue Health Tracking
-  body: To help users track projects and in-flight work GitLab now enables you to report on and quickly respond to the health of individual issues and epics by showing a red, amber, or green health status on your Epic Tree. Assign an issue a health status of On track (green), Needs attention (amber), or At risk (red) and see an aggregate report of health at the Epic level. Quickly view and analyze where a collection of work is at risk so you can open up the right discussions at the right time and keep work on track!
+  body: |
+    To help users track projects and in-flight work GitLab now enables you to report on and quickly respond to the health of individual issues and epics by showing a red, amber, or green health status on your Epic Tree.
+
+    Assign an issue a health status of **On track** (green), **Needs attention** (amber), or **At risk** (red) and see an aggregate report of health at the Epic level.
+
+    Quickly view and analyze where a collection of work is at risk so you can open up the right discussions at the right time and keep work on track!
   stage: Plan
   self-managed: true
   gitlab-com: true
@@ -30,7 +41,10 @@
   published_at: 2020-04-22
   release: 12.10
 - title: Import Issues from Jira to GitLab
-  body: Until now, the only way to get Jira issues into GitLab was manually, with our CSV importer, or by hand-rolling your own migration utility. GitLab 12.10 includes an MVC to automatically import your Jira issues into GitLab. This is the first of many planned enhancements to make transitioning from Jira to GitLab as frictionless as possible.
+  body: |
+    Until now, the only way to get Jira issues into GitLab was manually, with our CSV importer, or by hand-rolling your own migration utility.
+
+    GitLab 12.10 includes an [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc) to automatically import your Jira issues into GitLab. This is the first of [many planned enhancements](https://gitlab.com/groups/gitlab-org/-/epics/2738) to make transitioning from Jira to GitLab as frictionless as possible.
   stage: Plan
   self-managed: true
   gitlab-com: true
@@ -40,7 +54,10 @@
   published_at: 2020-04-22
   release: 12.10
 - title: Autoscaling GitLab CI jobs on AWS Fargate
-  body: You can now auto-scale GitLab CI on AWS Fargate with the MVC release of GitLab’s AWS Fargate Driver. With this new autoscaling pattern, GitLab’s AWS Fargate driver automatically runs each build in a separate and isolated container on Amazon’s Elastic Container Service (ECS) using a user-defined container image.
+  body: |
+    You can now auto-scale GitLab CI on AWS Fargate with the MVC release of GitLab’s AWS Fargate Driver.
+
+    With this new autoscaling pattern, [GitLab’s AWS Fargate driver](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/fargate) automatically runs each build in a separate and isolated container on Amazon’s Elastic Container Service (ECS) using a user-defined container image.
   stage: Verify
   self-managed: true
   gitlab-com: false

data/whats_new/202008180002_13_0.yml

 ---
 - title: Gitaly Cluster for High Availability Git Storage
-  body: GitLab now supports highly available Git storage without using NFS. High Availability (HA) configurations improve the availability of important systems, like Git storage, by removing single points of failure, detecting outages, and automatically switching to a replica. This means that an individual component of the system can fail without causing the end user to experience an outage. Access to Git repositories is critical to developers and businesses, because when an outage occurs, developers can’t push code, and deployments are blocked.
+  body: |
+    GitLab now supports highly available Git storage without using NFS. High Availability (HA) configurations improve the availability of important systems, like Git storage, by removing single points of failure, detecting outages, and automatically switching to a replica.
+
+    This means that an individual component of the system can fail without causing the end user to experience an outage. Access to Git repositories is critical to developers and businesses, because when an outage occurs, developers can’t push code, and deployments are blocked.
   stage: Create
   self-managed: true
   gitlab-com: false
@@ -10,17 +13,23 @@
   published_at: 2020-05-22
   release: 13.0
 - title: Auto Deploy to ECS
-  body: Until now, there hasn’t been a simple way to deploy to Amazon Web Services. As a result, GitLab users had to  spend a lot of time figuring out their own configuration. In GitLab 13.0, Auto DevOps has been extended to support deployment to AWS! GitLab users who are deploying to AWS Elastic Container Service (ECS) can now take advantage of Auto DevOps, even if they are not using Kubernetes.
+  body: |
+    Until now, there hasn’t been a simple way to deploy to Amazon Web Services. As a result, GitLab users had to  spend a lot of time figuring out their own configuration.
+
+    In GitLab 13.0, Auto DevOps has been extended to support deployment to AWS! GitLab users who are deploying to AWS Elastic Container Service (ECS) can now take advantage of Auto DevOps, even if they are not using Kubernetes.
   stage: Release
   self-managed: true
   gitlab-com: true
   packages: [All]
   url: https://docs.gitlab.com/ee/topics/autodevops/index.html#aws-ecs
-  image_url:
+  image_url: https://docs.gitlab.com/ee/ci/img/ecs_dashboard_v12_9.png
   published_at: 2020-05-22
   release: 13.0
 - title: View Epic Hierarchy on a Roadmap
-  body: When leveraging Multi-Level Epics, it can be difficult to keep track of where each child epic lives on the Roadmap. You can now quickly expand a parent epic on your roadmap to view all its child epics to ensure work is properly organized and your planned timeline is on track!
+  body: |
+    When leveraging Multi-Level Epics, it can be difficult to keep track of where each child epic lives on the Roadmap.
+
+    You can now quickly expand a parent epic on your roadmap to view all its child epics to ensure work is properly organized and your planned timeline is on track!
   stage: Plan
   self-managed: true
   gitlab-com: true
@@ -30,7 +39,10 @@
   published_at: 2020-05-22
   release: 13.0
 - title: Versioned Snippets
-  body: Snippets in GitLab are now version controlled by a Git repository. When editing a Snippet, each change creates a commit. Snippets can also be cloned to make edits locally, and then pushed back to the Snippet repository.
+  body: |
+    Snippets in GitLab are now version controlled by a Git repository. When editing a Snippet, each change creates a commit.
+
+    Snippets can also be cloned to make edits locally, and then pushed back to the Snippet repository.
   stage: Create
   self-managed: true
   gitlab-com: true
@@ -40,7 +52,10 @@
   published_at: 2020-05-22
   release: 13.0
 - title: Dark Theme in the Web IDE
-  body: For people who spend time working in code editors, the ability to customize the environment to match their preferences is important. Dark themes are some of the most popular for other editors and important for providing a comfortable experience. That's why we're excited that the GitLab Web IDE is now completely themed dark for users who choose the Dark syntax highlighting theme perference!
+  body: |
+    For people who spend time working in code editors, the ability to customize the environment to match their preferences is important. Dark themes are some of the most [popular](https://marketplace.visualstudio.com/search?target=VSCode&category=Themes&sortBy=Installs) for other editors and important for providing a comfortable experience.
+
+    That's why we're excited that the GitLab Web IDE is now completely themed dark for users who choose the **Dark** [syntax highlighting theme perference](https://docs.gitlab.com/ee/user/profile/preferences.html#syntax-highlighting-theme)!
   stage: Create
   self-managed: true
   gitlab-com: true

data/whats_new/202008180003_13_01.yml

 ---
 - title: Manage IT Alerts in GitLab
-  body: GitLab is excited to introduce Alert Management to aggregate multiple IT service alerts in one interface, helping your team triage alerts and promote them to Incidents. We’ve added the ability to triage alerts in a list view, view alert details, assign alerts, update the status of alerts, and create Incident Issues from Alerts.
+  body: |
+    GitLab is excited to introduce Alert Management to aggregate multiple IT service alerts in one interface, helping your team triage alerts and promote them to Incidents.
+
+    We’ve added the ability to triage alerts in a [list view](https://gitlab.com/groups/gitlab-org/-/epics/2986), [view alert details](https://gitlab.com/groups/gitlab-org/-/epics/2987), [assign alerts](https://gitlab.com/groups/gitlab-org/-/epics/3349), [update the status of alerts](https://gitlab.com/gitlab-org/gitlab/-/issues/214542), and [create Incident Issues from Alerts](https://gitlab.com/gitlab-org/gitlab/-/issues/213909).
   stage: Monitor
   self-managed: true
   gitlab-com: true
@@ -10,7 +13,10 @@
   published_at: 2020-06-22
   release: 13.1
 - title: Accessibility Testing Merge Request Widget
-  body: Today, developers who want to ensure their application is accessible to everyone suffer from slow feedback loops, which make it difficult to catch degradations in their code. In GitLab 13.1, merge requests can have a widget that details accessibility degradations related to the changed pages. This will immediately show developers the impact of their changes, which helps prevent degradations before they are merged and deployed.
+  body: |
+    Today, developers who want to ensure their application is accessible to everyone suffer from slow feedback loops, which make it difficult to catch degradations in their code.
+
+    In GitLab 13.1, merge requests can have a widget that details accessibility degradations related to the changed pages. This will immediately show developers the impact of their changes, which helps prevent degradations before they are merged and deployed.
   stage: Verify
   self-managed: true
   gitlab-com: true
@@ -20,7 +26,8 @@
   published_at: 2020-06-22
   release: 13.1
 - title: Mark any Design Thread as Resolved
-  body: When you receive lots of feedback on a Design, the number of comment pins can build up quickly! As your discussion thread grows, it gets hard to know which discussions are complete and which still need work. Now you’ll have the ability to mark any comment as Resolved to signify that it is now complete. Even better — your resolved comment pins will disappear from the Design so you can focus on what’s left!
+  body: |
+    When you receive lots of feedback on a Design, the number of comment pins can build up quickly! As your discussion thread grows, it gets hard to know which discussions are complete and which still need work. Now you’ll have the ability to mark any comment as **Resolved** to signify that it is now complete. Even better — your **Resolved Comment** pins will disappear from the Design so you can focus on what’s left!
   stage: Create
   self-managed: true
   gitlab-com: true
@@ -30,7 +37,8 @@
   published_at: 2020-06-22
   release: 13.1
 - title: Merge Request Reviews moved to Core
-  body: Originally introduced in GitLab 11.4 as a GitLab Premium feature, Merge Request Reviews allow merge request reviewers to submit multiple comments at once, cutting down on notification noise for the merge request author, and allowing for a more cohesive and streamlined review process.
+  body: |
+    Originally introduced in GitLab 11.4 as a GitLab Premium feature, Merge Request Reviews allow merge request reviewers to submit multiple comments at once, cutting down on notification noise for the merge request author, and allowing for a more cohesive and streamlined review process.
   stage: Create
   self-managed: true
   gitlab-com: true

data/whats_new/202008210001_13_02.yml

 ---
 - title: Assign Issues to Iterations
-  body: Prior to this release, there was no way to associate an issue with more than one timebox in GitLab. This has been particularly problematic for teams that follow Scrum or XP. Such teams often need to associate issues with iterations/sprints, while also rolling that issue up to longer-running milestones, such as program increments. Instead of having to decide whether to use milestones for sprints or program increments and track the other in a spreadsheet, you can now assign issues to iterations, milestones, or both.
+  body: |
+    Prior to this release, there was no way to associate an issue with more than one timebox in GitLab. This has been particularly problematic for teams that follow Scrum or XP. Such teams often need to associate issues with iterations/sprints, while also rolling that issue up to longer-running milestones, such as program increments.
+
+    Instead of having to decide whether to use milestones for sprints or program increments and track the other in a spreadsheet, you can now assign issues to iterations, milestones, or both.
   stage: Plan
   self-managed: true
   gitlab-com: true
@@ -10,7 +13,10 @@
   published_at: 2020-07-22
   release: 13.2
 - title: Container Host Monitoring and Blocking
-  body: We’re pleased to announce the first release of Container Host Security. This initial feature, container host monitoring and blocking, allows security administrators to secure their running containers at the host level by monitoring and optionally blocking unexpected activity. Such activity includes process starts, file changes, or opened network ports. This feature uses Falco to provide the monitoring functionality and AppArmor and Pod Security Policies for the blocking functionality.
+  body: |
+    We’re pleased to announce the first release of [Container Host Security](https://about.gitlab.com/direction/protect/container_host_security/). This initial feature, container host monitoring and blocking, allows security administrators to secure their running containers at the host level by monitoring and optionally blocking unexpected activity.
+
+    Such activity includes process starts, file changes, or opened network ports. This feature uses [Falco](https://falco.org/) to provide the monitoring functionality and [AppArmor](https://www.kernel.org/doc/html/v4.15/admin-guide/LSM/apparmor.html) and [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for the blocking functionality.
   stage: Defend
   self-managed: true
   gitlab-com: true
@@ -20,7 +26,10 @@
   published_at: 2020-07-22
   release: 13.2
 - title: Official GitLab-Figma Plugin
-  body: Recently, the GitLab product design team and our open source Pajamas Design System switched over to Figma. We decided to build a new Figma plugin, which allows for easy uploads from Figma to issues on GitLab.com. This makes it quick and easy to collaborate on Designs. Connect your design environment with your source code management in a seamless workflow.
+  body: |
+    Recently, the GitLab product design team and our open source [Pajamas Design System](https://design.gitlab.com/) switched over to Figma. We decided to build a new Figma plugin, which allows for easy uploads from Figma to issues on GitLab.com.
+
+    This makes it quick and easy to collaborate on Designs. Connect your design environment with your source code management in a seamless workflow.
   stage: Create
   self-managed: false
   gitlab-com: true
@@ -30,7 +39,12 @@
   published_at: 2020-07-22
   release: 13.2
 - title: Cluster health monitoring now available in Core
-  body: To understand system performance, your development team must monitor the health and performance of the underlying infrastructure. We want our metrics solution to be available to all GitLab users, so as part of our 2020 gift, we’ve moved cluster health in the Monitor stage from GitLab Ultimate to GitLab Core. Beginning with GitLab 13.2, all users can connect a cluster and monitor its health in the GitLab user interface.
+  body: |
+    To understand system performance, your development team must monitor the health and performance of the underlying infrastructure.
+
+    We want our metrics solution to be available to all GitLab users, so as part of our [2020 gift](https://about.gitlab.com/blog/2019/12/16/observability/), we’ve moved cluster health in the Monitor stage from GitLab Ultimate to GitLab Core.
+
+    Beginning with GitLab 13.2, all users can connect a cluster and monitor its health in the GitLab user interface.
   stage: Monitor
   self-managed: true
   gitlab-com: true

data/whats_new/202009150001_13_03.yml

 ---
 - title: Coverage-guided fuzz testing for Go and C/C++ applications
-  body: You can now run coverage-guided fuzz tests against your Go and C/C++ apps. This is a great way to start finding security issues and bugs that other security scanners and traditional QA may miss. Coverage-guided fuzz testing uses contextual information about your app to randomly generate inputs and find crashes or other faults that you can then fix before they affect users in production.
+  body: |
+    You can now run coverage-guided fuzz tests against your Go and C/C++ apps. This is a great way to start finding security issues and bugs that other security scanners and traditional QA may miss.
+
+    Coverage-guided fuzz testing uses contextual information about your app to randomly generate inputs and find crashes or other faults that you can then fix before they affect users in production.
   stage: Secure
   self-managed: true
   gitlab-com: true
@@ -10,7 +13,8 @@
   published_at: 2020-08-22
   release: 13.3
 - title: Create a matrix of jobs using a simple syntax
-  body: GitLab’s child/parent pipelines let you write your own code to generate an entire pipeline YAML. This is a powerful way to generate custom behaviors, including generating jobs at runtime. This might not be needed for simpler scenarios where you just want to create multiple similar jobs for a defined set of cases. In this release you can find a new matrix keyword that works along with parallel to handle the creation of multiple jobs for you, each with different variables.
+  body: |
+    GitLab’s [child/parent pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/16094) let you write your own code to generate an entire pipeline YAML. This is a powerful way to generate custom behaviors, including generating jobs at runtime. This might not be needed for simpler scenarios where you just want to create multiple similar jobs for a defined set of cases. In this release you can find a new `matrix` keyword that works along with `parallel` to handle the creation of multiple jobs for you, each with different variables.
   stage: Verify
   self-managed: true
   gitlab-com: true
@@ -20,7 +24,12 @@
   published_at: 2020-08-22
   release: 13.3
 - title: On-demand DAST scans
-  body: Dynamic Application Security Testing at GitLab has always been focused on integrating DAST into the DevOps pipeline and enabling developers to scan their review app, running website, or API for vulnerabilities as early as possible. However, there are times when it is necessary to run a DAST scan against an already deployed application when no code changes have been made and no Merge Request has been created. These scans could be needed for audit or compliance reasons, to debug and reproduce an issue that has been found, or to support teams who do not commit code, such as security analysts. Because of the need for DAST scans that are not triggered by a code change or MR, on-demand DAST testing is now available. You don’t need configuration files or code to start running on-demand scans. Configuration options for on-demand DAST scans are available within the GitLab UI.
+  body: |
+    Dynamic Application Security Testing at GitLab has always been focused on integrating DAST into the DevOps pipeline and enabling developers to scan their review app, running website, or API for vulnerabilities as early as possible.
+
+    However, there are times when it is necessary to run a DAST scan against an already deployed application when no code changes have been made and no Merge Request has been created. These scans could be needed for audit or compliance reasons, to debug and reproduce an issue that has been found, or to support teams who do not commit code, such as security analysts.
+
+    Because of the need for DAST scans that are not triggered by a code change or MR, on-demand DAST testing is now available. You don’t need configuration files or code to start running on-demand scans. Configuration options for on-demand DAST scans are available within the GitLab UI.
   stage: Secure
   self-managed: true
   gitlab-com: true
@@ -30,7 +39,10 @@
   published_at: 2020-08-22
   release: 13.3
 - title: SAST security analyzers available for all
-  body: We want to help developers write better code and worry less about common security mistakes. Static Application Security Testing (SAST) helps prevent security vulnerabilities by allowing developers to easily identify common security issues as code is being committed and mitigate proactively. As part of our community stewardship commitment we have made all 15 of our open source based SAST analyzers available in every GitLab tier. This allows ALL GitLab users developing in any of our 18 supported languages and frameworks to leverage GitLab SAST in their projects.
+  body: |
+    We want to help developers write better code and worry less about common security mistakes. [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) helps prevent security vulnerabilities by allowing developers to easily identify common security issues as code is being committed and mitigate proactively.
+
+    As part of our [community stewardship commitment](https://about.gitlab.com/company/stewardship/#promises) we have made [all 15 of our open source based SAST analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) available in every GitLab tier. This allows ALL GitLab users developing in any of our [18 supported languages and frameworks](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) to leverage GitLab SAST in their projects.
   stage: Secure
   self-managed: true
   gitlab-com: true

data/whats_new/202009300001_13_04.yml

 ---
 - title: Use HashiCorp Vault secrets in CI jobs
-  body: In GitLab 12.10, GitLab introduced functionality for GitLab Runner to fetch and inject secrets into CI jobs. GitLab is now expanding the JWT Vault Authentication method by building a new secrets syntax in the .gitlab-ci.yml file. This makes it easier for you to configure and use HashiCorp Vault with GitLab.
+  body: |
+    In GitLab 12.10, GitLab introduced functionality for GitLab Runner to fetch and inject secrets into CI jobs. GitLab is now expanding the [JWT Vault Authentication method](https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/) by building a new `secrets` syntax in the `.gitlab-ci.yml` file. This makes it easier for you to configure and use HashiCorp Vault with GitLab.
   stage: Release
   self-managed: true
   gitlab-com: true
@@ -10,7 +11,14 @@
   published_at: 2020-09-22
   release: 13.4
 - title: Introducing the GitLab Kubernetes Agent
-  body: "GitLab's Kubernetes integration has long enabled deployment to Kubernetes clusters without manual setup. Many users have enjoyed the ease-of-use, while others have run into some challenges. The current integration requires your cluster to be open to the Internet for GitLab to access it. For many organizations, this isn't possible, because they must lock down their cluster access for security, compliance, or regulatory purposes. To work around these restrictions, users needed to create custom tooling on top of GitLab, or they couldn't use the feature. Today, we're announcing the GitLab Kubernetes Agent: a new way to deploy to Kubernetes clusters. The Agent runs inside of your cluster, so you don't need to open it to the internet. The Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to the cluster. No matter what method of GitOps you use, GitLab has you covered."
+  body: |
+    GitLab's Kubernetes integration has long enabled deployment to Kubernetes clusters without manual setup. Many users have enjoyed the ease-of-use, while others have run into some challenges. The current integration requires your cluster to be open to the Internet for GitLab to access it.
+
+    For many organizations, this isn't possible, because they must lock down their cluster access for security, compliance, or regulatory purposes. To work around these restrictions, users needed to create custom tooling on top of GitLab, or they couldn't use the feature.
+
+    Today, we're announcing the GitLab Kubernetes Agent: a new way to deploy to Kubernetes clusters. The Agent runs inside of your cluster, so you don't need to open it to the internet. The Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to the cluster.
+
+    No matter what method of GitOps you use, GitLab has you covered.
   stage: Configure
   self-managed: true
   gitlab-com: false
@@ -20,7 +28,10 @@
   published_at: 2020-09-22
   release: 13.4
 - title: Grant users deployment permissions without code access
-  body: If your team needs to maintain separation of duties between team members who own development, and team members who own deployments, the permissions paradigm in GitLab has made this challenging. In GitLab 13.4, you can give non-code contributors permission to approve merge requests for deployment, and actually deploy code, without also granting them maintainer access.
+  body: |
+    If your team needs to maintain separation of duties between team members who own development, and team members who own deployments, the permissions paradigm in GitLab has made this challenging.
+
+    In GitLab 13.4, you can give non-code contributors permission to approve merge requests for deployment, and actually deploy code, without also granting them maintainer access.
   stage: Release
   self-managed: true
   gitlab-com: true
@@ -30,7 +41,12 @@
   published_at: 2020-09-22
   release: 13.4
 - title: Security Center
-  body: We've made a foundational change to security visibility and management in GitLab. The Instance Security Dashboard has been transformed into a Security Center. The biggest change is introducing a new menu structure. Rather than a single page, you can now find a Security Dashboard, Vulnerability Report, and Settings area. While the functionality hasn't changed, breaking things apart enables future enhancements that would have been difficult otherwise. This also creates a top-level framework for including other security-related functionality in the future. The dedicated Vulnerability Report now has more room to display important details and inherits those currently found on the Project vulnerability list. Separating the vulnerability metrics widgets into their own area creates a true Security Dashboard.
+  body: |
+    We've made a foundational change to security visibility and management in GitLab. The Instance Security Dashboard has been transformed into a Security Center. The biggest change is introducing a new menu structure. Rather than a single page, you can now find a Security Dashboard, Vulnerability Report, and Settings area.
+
+    While the functionality hasn't changed, breaking things apart enables future enhancements that would have been difficult otherwise. This also creates a top-level framework for including other security-related functionality in the future.
+
+    The dedicated Vulnerability Report now has more room to display important details and inherits those currently found on the Project vulnerability list. Separating the vulnerability metrics widgets into their own area creates a true Security Dashboard.
   stage: Secure
   self-managed: true
   gitlab-com: true
@@ -40,7 +56,10 @@
   published_at: 2020-09-22
   release: 13.4
 - title: Feature Flags made available in GitLab Starter
-  body: Earlier this year, GitLab committed to moving 18 features to our open source core product. With this release of GitLab we've finished moving Feature Flags to Starter, and we are continuing to migrate our Feature Flag service to Core in GitLab 13.5. We're excited about bringing these features to more users and seeing what use cases and workflows you use them for.
+  body: |
+    Earlier this year, GitLab committed to [moving 18 features](https://about.gitlab.com/blog/2020/03/30/new-features-to-core/) to our open source core product. With this release of GitLab we've finished moving Feature Flags to Starter, and we are continuing to migrate our Feature Flag service to Core in [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/212318).
+
+    We're excited about bringing these features to more users and seeing what use cases and workflows you use them for.
   stage: Release
   self-managed: true
   gitlab-com: true
@@ -50,7 +69,10 @@
   published_at: 2020-09-22
   release: 13.4
 - title: Quick navigation using the Search bar
-  body: When navigating through GitLab, sometimes you just want to go to a specific project and not a search result page. Using the Global search bar, you can now quickly jump to recent issues, groups, projects, settings, and help topics. You can even use the `/` keyboard shortcut to move the cursor to the search bar, to navigate GitLab even more efficiently!
+  body: |
+    When navigating through GitLab, sometimes you just want to go to a specific project and not a search result page. Using the Global search bar, you can now quickly jump to recent issues, groups, projects, settings, and help topics.
+
+    You can even use the `/` keyboard shortcut to move the cursor to the search bar, to navigate GitLab even more efficiently!
   stage: Enablement
   self-managed: true
   gitlab-com: true

data/whats_new/202010230001_13_05.yml

 ---
 - title: Group wikis
-  body: For many teams, using GitLab wikis for planning and documentation is a critical part of their workflow. Wikis are so popular that they get over a million views each month on GitLab.com. Despite this popularity, teams have struggled with the limitation that wikis were only available at the project level. Teams working on multiple projects needed to create separate wikis for each repository, leading to a fragmented experience. In Gitlab 13.5, we are so excited to bring you group wikis! This was the most upvoted feature in the entire GitLab backlog. While highly requested, making a large project-only feature like wikis available at the group level has been a non-trivial operation. We’ve worked tirelessly over the past year to make it happen and now we can't wait to get it in your hands and hear your feedback.
+  body: |
+    For many teams, using GitLab wikis for planning and documentation is a critical part of their workflow. Wikis are so popular that they get over a million views each month on GitLab.com.
+
+    Despite this popularity, teams have struggled with the limitation that wikis were only available at the project level. Teams working on multiple projects needed to create separate wikis for each repository, leading to a fragmented experience.
+
+    In Gitlab 13.5, we are so excited to bring you group wikis! With [680 upvotes](https://gitlab.com/gitlab-org/gitlab/-/issues/13195) this was the most upvoted feature in the entire GitLab backlog. While highly requested, making a large project-only feature like wikis available at the group level has been a non-trivial operation.
+
+    We know a lot of folks have been looking forward to this feature and shared their input pre-release. We hope all of you will continue to weigh in now that group wikis are available and we’ve opened up a [dedicated issue](https://gitlab.com/gitlab-org/gitlab/-/issues/267593) for your feedback.
   stage: Create
   self-managed: true
   gitlab-com: true
@@ -10,7 +17,10 @@
   published_at: 2020-10-22
   release: 13.5
 - title: Install the GitLab Kubernetes Agent with Omnibus GitLab
-  body: "Last month we introduced the GitLab Kubernetes Agent for self-managed GitLab instances installed with Helm. This release adds support for the official Linux package. In this new Kubernetes integration, the Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to your cluster."
+  body: |
+    Last month we introduced the [GitLab Kubernetes Agent](https://about.gitlab.com/releases/2020/09/22/gitlab-13-4-released/#introducing-the-gitlab-kubernetes-agent) for self-managed GitLab instances installed with Helm.
+
+    This release adds support for the [official Linux package](https://about.gitlab.com/install/). In this new Kubernetes integration, the Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to your cluster. You can learn more about [how the Kubernetes Agent works now](https://docs.gitlab.com/ee/user/clusters/agent/) and [check out our vision](https://about.gitlab.com/direction/configure/kubernetes_management/) to see what’s in store.
   stage: Configure
   self-managed: true
   gitlab-com: false
@@ -20,7 +30,12 @@
   published_at: 2020-10-22
   release: 13.5
 - title: Snippets with multiple files
-  body: Engineers often use Snippets to share examples of code, reusable components, logs, and other items. These valuable pieces of information often require additional context and may require more than one file. Sharing a link to multiple files or multiple Snippets makes it challenging for users to piece this context together and understand the scope of what is being presented. GitLab now supports multiple files inside of a single Snippet, so you can create Snippets composed of multiple parts. It broadens its use to endless possibilities!
+  body: |
+    Engineers often use Snippets to share examples of code, reusable components, logs, and other items. These valuable pieces of information often require additional context and may require more than one file. Sharing a link to multiple files or multiple Snippets makes it challenging for users to piece this context together and understand the scope of what is being presented.
+
+    In GitLab 13.0, we laid a foundation for Snippets by giving them [version control](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/#versioned-snippets) support based on a Git repository. Version control and the history it provides are an important piece of context when looking at code and understanding its purpose, but it may not be everything.
+
+    GitLab now supports multiple files inside of a single Snippet, so you can create Snippets composed of multiple parts. It broadens its use to endless possibilities!
   stage: Create
   self-managed: true
   gitlab-com: true
@@ -30,7 +45,10 @@
   published_at: 2020-10-22
   release: 13.5
 - title: Enable instance-level shared runners when viewing groups
-  body: GitLab SaaS includes Linux and Windows runners, which are easy to use agents that run your GitLab CI/CD pipeline jobs. These runners, visible in the GitLab.com UI as "shared runners," are enabled by default and can be disabled for each project. However, some organizations require their CI/CD jobs to run only on self-managed runners, and so disabling the use of instance-level shared runners on each project resulted in unnecessary administrative overhead. Now administrators can enable or disable shared runners at the group level. Administrators can also allow groups to override the global setting and use shared runners on a project-by-project basis.
+  body: |
+    GitLab SaaS includes Linux and Windows runners, which are easy to use agents that run your GitLab CI/CD pipeline jobs. These runners, visible in the GitLab.com UI as "shared runners," are enabled by default and can be disabled for each project. However, some organizations require their CI/CD jobs to run only on self-managed runners, and so disabling the use of instance-level shared runners on each project resulted in unnecessary administrative overhead.
+
+    Now administrators can enable or disable shared runners at the group level. Administrators can also allow groups to override the global setting and use shared runners on a project-by-project basis.
   stage: Verify
   self-managed: true
   gitlab-com: true
@@ -40,7 +58,10 @@
   published_at: 2020-10-22
   release: 13.5
 - title: Feature Flags flexible rollout strategy
-  body: When you use the percent rollout strategy today, the stickiness, or the experience consistency, is determined only by the user ID. This can be limiting; as an example, anonymous users cannot be affected by this strategy. We have improved this rollout strategy by enabling you to define the stickiness based on session ID, user ID, or at random (no stickiness). This gives you more control over the rollout and allows you to support stickiness for anonymous users.
+  body: |
+    When you use the `percent rollout` strategy today, the stickiness, or the experience consistency, is determined only by the user ID. This can be limiting; as an example, anonymous users cannot be affected by this strategy.
+
+    We have improved this rollout strategy by enabling you to define the stickiness based on session ID, user ID, or at random (no stickiness). This gives you more control over the rollout and allows you to support stickiness for anonymous users.
   stage: Release
   self-managed: true
   gitlab-com: true
@@ -50,7 +71,10 @@
   published_at: 2020-10-22
   release: 13.5
 - title: SAST support for iOS and Android mobile apps
-  body: GitLab SAST now supports mobile applications including iOS apps written in Objective-C and Swift as well as Android apps written in Java and Kotlin powered by the Mobile Security Framework (MobSF). Initially this analyzer supports source code analysis but we intend to expand support for binary scanning of .ipa and .apk files in the near future. This feature was a generous contribution by the H-E-B Digital team.
+  body: |
+    GitLab [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) now supports mobile applications including iOS apps written in Objective-C and Swift as well as Android apps written in Java and Kotlin powered by the [Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF).  Initially this analyzer supports source code analysis but we [intend to expand support for binary scanning](https://gitlab.com/gitlab-org/gitlab/-/issues/269915) of `.ipa` and `.apk` files in the near future.
+
+    This feature was a generous contribution by the [H-E-B Digital](https://digital.heb.com/) team.
   stage: Secure
   self-managed: true
   gitlab-com: true

data/whats_new/202011230001_13_06.yml

 ---
 - title: Auto Deploy to EC2
-  body: Auto DevOps has been expanded to support deployments to Amazon Web Services. You can now deploy to AWS Cloud Compute (EC2) and take advantage of Auto DevOps, even without Kubernetes. To enable this workflow, you must enable Auto DevOps and define the AWS-typed environment variables AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_DEFAULT_REGION. This allows you to provision your own infrastructure by leveraging the AWS CloudFormation API. Then, you can push your previously built artifact to an AWS S3 bucket, and deploy the content to an AWS EC2 instance. Your EC2 deployment then automatically builds you a complete, automatic delivery pipeline without extra manual steps.
+  body: |
+    Auto DevOps has been expanded to support deployments to Amazon Web Services. You can now deploy to AWS Cloud Compute (EC2) and take advantage of Auto DevOps, even without Kubernetes.
+
+    To enable this workflow, you must enable Auto DevOps and define the AWS-typed environment variables `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_DEFAULT_REGION`. This allows you to provision your own infrastructure by leveraging the [AWS CloudFormation API](https://aws.amazon.com/cloudformation/).
+
+    Then, you can push your previously built artifact to an [AWS S3 bucket](https://aws.amazon.com/s3/), and deploy the content to an [AWS EC2](https://aws.amazon.com/ec2/?ec2-whats-new.sort-by=item.additionalFields.postDateTime&ec2-whats-new.sort-order=desc) instance. Your EC2 deployment then automatically builds you a complete, automatic delivery pipeline without extra manual steps.
   stage: Release
   self-managed: true
   gitlab-com: true
@@ -10,7 +15,10 @@
   published_at: 2020-11-22
   release: 13.6
 - title: Display Code Quality severity ratings
-  body: The Code Quality feature in GitLab is great at showing what quality violations exist in a project or are changing in the Merge Request. However, understanding which of those violations is the most important is not clear in the GitLab interface today. With the Full Code Quality Report and Merge Request Widget, now you can see the severity rating. This makes it easy for you to understand which code quality violations are most important to resolve before merging and reduces the technical debt in your project.
+  body: |
+    The Code Quality feature in GitLab is great at showing what quality violations exist in a project or are changing in the Merge Request. However, understanding which of those violations is the most important is not clear in the GitLab interface today.
+
+    With the Full Code Quality Report and Merge Request Widget, now you can see the severity rating. This makes it easy for you to understand which code quality violations are most important to resolve before merging and reduces the technical debt in your project.
   stage: Verify
   self-managed: true
   gitlab-com: true
@@ -20,7 +28,14 @@
   published_at: 2020-11-22
   release: 13.6
 - title: Display code coverage data for selected projects
-  body: In 13.4, we released the first iteration of Code Coverage data for Groups that enables you to compare the coverage of multiple projects and download the data in a single file from a single screen. However, to analyze the data, you had to open the file to check it manually, and probably imported it into a spreadsheet for further analysis. In GitLab 13.6, you can now select specific projects in a group to see their latest coverage values directly in GitLab itself without needing to download a file or waste development time accessing code coverage data.
+  body: |
+    In 13.4, we released the first iteration of [Code Coverage data for Groups](https://about.gitlab.com/releases/2020/09/22/gitlab-13-4-released/#code-coverage-data-for-all-projects-in-a-group) that enables you to compare the coverage of multiple projects and download the data in a single file from a single screen.
+
+    However, to analyze the data, you had to open the file to check it manually, and probably imported it into a spreadsheet for further analysis.
+
+    In GitLab 13.6, you can now select specific projects in a group to see their latest coverage values directly in GitLab itself without needing to download a file or waste development time accessing code coverage data.
+
+    We welcome feedback on the functionality and possible iterations for this feature in our [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/231515).
   stage: Verify
   self-managed: true
   gitlab-com: true
@@ -30,7 +45,16 @@
   published_at: 2020-11-22
   release: 13.6
 - title: Group-level management of project integrations
-  body: In GitLab 13.3, we added the ability to enable an integration across an entire instance. With GitLab 13.6, that feature is being expanded to allow integrations to be managed at the group level as well! Group owners can now add an integration to a group, and that integration will be inherited by all projects under that group. This has the potential for saving massive amounts of time, as many organizations have specific integrations that they want rolled out to every project they create. A great example of this is using our Jira integration. If you're using Jira, it's almost always across the whole company. Some of these companies have _thousands of projects_ and therefore had to configure each and every one of those integrations individually.With group-level management of project integrations, you can add the integration at each parent group, reducing the amount of configuration required by orders of magnitude!
+  body: |
+    In GitLab 13.3, we added the ability to [enable an integration across an entire instance](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#instance-level-project-integration-management-for-external-services). With GitLab 13.6, that feature is being expanded to allow integrations to be managed at the group level as well! Group owners can now add an integration to a group, and that integration will be inherited by all projects under that group.
+
+    This has the potential for saving massive amounts of time, as many organizations have specific integrations that they want rolled out to every project they create.
+
+    A great example of this is using our [Jira integration](https://docs.gitlab.com/ee/user/project/integrations/jira.html). If you're using Jira, it's almost always across the whole company. Some of these companies have _thousands of projects_ and therefore had to configure each and every one of those integrations individually.
+
+    With group-level management of project integrations, you can add the integration at each parent group, reducing the amount of configuration required by orders of magnitude!
+
+    Read more in [our announcement on the GitLab blog](https://about.gitlab.com/blog/2020/11/19/integration-management/).
   stage: Create
   self-managed: true
   gitlab-com: true
@@ -40,7 +64,14 @@
   published_at: 2020-11-22
   release: 13.6
 - title: Milestone Burnup Charts and historically accurate reporting
-  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. This change only applies to milestones and iterations created in GitLab 13.6 or later. Milestones created prior to 13.6 will still have access to legacy burndown charts.
+  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.
+
+    We also refactored burndown charts to use immutable [resource state events](https://docs.gitlab.com/ee/api/resource_state_events.html#issues) that ensure that milestone and iteration charts remain historically accurate even after you’ve moved issues to another timebox.
+
+    This change only applies to milestones and iterations created in GitLab 13.6 or later. Milestones created prior to 13.6 will still have access to [legacy burndown charts](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html#fixed-burndown-charts).
   stage: Plan
   self-managed: true
   gitlab-com: true

spec/fixtures/whats_new/20201225_01_01.yml

 ---
 - title: It's gonna be a bright
+  body: |
+    ## It's gonna be a bright
   self-managed: true
   gitlab-com: false
   packages: ["Premium", "Ultimate"]

spec/fixtures/whats_new/20201225_01_02.yml

 ---
 - title: bright
+  body: |
+    ## bright
   self-managed: true
   gitlab-com: false
   packages: ["Premium", "Ultimate"]

spec/fixtures/whats_new/20201225_01_05.yml

 ---
 - title: bright and sunshinin' day
+  body: |
+    ## bright and sunshinin' day
   self-managed: true
   gitlab-com: false
   packages: ["Premium", "Ultimate"]
   release: '01.05'
 - title: I think I can make it now the pain is gone
+  body: |
+    ## I think I can make it now the pain is gone
   self-managed: false
   gitlab-com: true
   packages: ["Premium", "Ultimate"]

spec/models/release_highlight_spec.rb

@@ -86,6 +86,17 @@ RSpec.describe ReleaseHighlight do
         expect(subject[:next_page]).to eq(2)
       end
 
+      it 'parses the body as markdown and returns html' do
+        expect(subject[:items].first['body']).to match("<h2 id=\"bright-and-sunshinin-day\">bright and sunshinin’ day</h2>")
+      end
+
+      it 'logs an error if theres an error parsing markdown for an item, and skips it' do
+        allow(Kramdown::Document).to receive(:new).and_raise
+
+        expect(Gitlab::ErrorTracking).to receive(:track_exception)
+        expect(subject[:items]).to be_empty
+      end
+
       context 'when Gitlab.com' do
         let(:dot_com) { true }
 
@@ -95,14 +106,11 @@ RSpec.describe ReleaseHighlight do
         end
       end
 
-      context 'when recent release items do NOT exist' do
-        before do
+      context 'YAML parsing throws an exception' do
+        it 'fails gracefully and logs an error' do
           allow(YAML).to receive(:safe_load).and_raise(Psych::Exception)
 
           expect(Gitlab::ErrorTracking).to receive(:track_exception)
-        end
-
-        it 'fails gracefully and logs an error' do
           expect(subject).to be_nil
         end
       end