description:|# Do not modify this line, instead modify the lines below.
GitLab Flavored Markdown includes extensions to support [Mermaid, PlantUML, and Kroki diagrams](https://docs.gitlab.com/ee/user/markdown.html#diagrams-and-flowcharts) but writing anything other than the most basic diagrams can be cumbersome without a live preview. You can toggle between the raw source and static preview and there are external tools you can use to write these diagrams, but the shift away from your content can be distracting.
GitLab 15.2 introduces a live rendered preview of your diagram in the wiki's WYSIWYG editor. Now, as you write your diagram in a specialized code block we will detect the diagram type and display a preview icon. When enabled, the live preview renders above the code block and updates as you type, so you can ensure your formatting is correct and the output will be exactly what you expect.
Capturing what happened during an incident is an important practice that facilitates learning and the opportunity for improvement. Yet, asking incident responders to take on additional administrative tasks when they're busy fire-fighting, or trying to reconstruct the timeline of events post incident lead to incomplete or less than accurate information.
GitLab incident timeline is designed to make information capture during an incident, or post incident, easy and efficient. In the Incident timeline MVC, we make it possible to add new timeline events manually, delete a timeline event, and view the incident timeline in a dedicated tab within an incident issue.
Merge request reports are an important part of code review, providing insights into the impact of changes and improvements to meet project standards.
Report widgets now all follow design guidelines for layout, hierarchy, and content sections, making them consistent, scannable, and utilitarian. These improvements make it easier for you to find actionable information in each report.
In this release, we added a new trend chart for the DORA [Change failure rate](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html) metric. This chart shows the percentage of deployments that cause an incident in a production environment. GitLab measures the change failure rate as the number of [incidents](https://docs.gitlab.com/ee/operations/incident_management/incidents.html) divided by the number of deployments to a production environment during a given time period.
This is the fourth DORA chart available in GitLab that provides insights into [value stream velocity and reliability trends](https://about.gitlab.com/blog/2022/06/20/gitlab-value-stream-management-and-dora/).
Limiting access to requests from a trusted set of IP addresses may improve security. Until now, only the API and UI supported such access restrictions; SSH access was blocked entirely. SSH now also adheres to this restriction, and grants access only to requests coming from IP addresses in your list.
Your security and compliance teams can now apply policies uniformly to all projects by scanning execution policies at the group and subgroup levels. This functionality is especially helpful for large organizations who have a large number of projects. Policies defined for the group or subgroup will flow down and apply to all child projects. To get started, ask your group owner to link a security policy project to your group on the **Security & Compliance > Policies** page.
Currently scan execution policies are the only policy type that is supported at the group and subgroup levels. You can track the efforts to add group and subgroup level support for scan result policies in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/7622).
You can select different [pull policies](https://docs.gitlab.com/runner/executors/docker.html#how-pull-policies-work) for how a GitLab Runner downloads Docker images in CI/CD jobs. `always` (the default behavior) ensures the image is always downloaded, `if-not-present` downloads an image only when a local version does not exist, and `never` only uses the local version (never download an image).
Previously, you could define the pull policy only at the runner level. In this release we've added the ability to define the pull policy at the pipeline level. Use `pull_policy` in your `.gitlab-ci.yml` to define different pull policies at the job or pipeline level. This feature is not supported by shared runners.
