kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2022-07-30 03:11:58 +00:00
parent f15be95ca1
commit 285277f94e
45 changed files with 796 additions and 792 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
app/assets/javascripts/whats_new/components/app.vue
View File

@ -79,7 +79,7 @@ export default {
@bottomReached="bottomReached"
>
<template #items>
<feature v-for="feature in features" :key="feature.title" :feature="feature" />
<feature v-for="feature in features" :key="feature.name" :feature="feature" />
</template>
</gl-infinite-scroll>
</template>

31
app/assets/javascripts/whats_new/components/feature.vue
View File

@ -37,35 +37,35 @@ export default {
<div class="gl-py-6 gl-px-6 gl-border-b-1 gl-border-b-solid gl-border-b-gray-100">
<gl-link
v-if="feature.image_url"
:href="feature.url"
:href="feature.documentation_link"
target="_blank"
class="gl-display-block"
data-testid="whats-new-image-link"
data-track-action="click_whats_new_item"
:data-track-label="feature.title"
:data-track-property="feature.url"
:data-track-label="feature.name"
:data-track-property="feature.documentation_link"
>
<div
class="whats-new-item-image gl-bg-size-cover"
:style="`background-image: url(${feature.image_url});`"
>
<span class="gl-sr-only">{{ feature.title }}</span>
<span class="gl-sr-only">{{ feature.name }}</span>
</div>
</gl-link>
<gl-link
:href="feature.url"
:href="feature.documentation_link"
target="_blank"
class="whats-new-item-title-link gl-display-block gl-mt-4 gl-mb-1"
data-track-action="click_whats_new_item"
:data-track-label="feature.title"
:data-track-property="feature.url"
:data-track-label="feature.name"
:data-track-property="feature.documentation_link"
>
<h5 class="gl-font-lg gl-my-0" data-test-id="feature-title">{{ feature.title }}</h5>
<h5 class="gl-font-lg gl-my-0" data-test-id="feature-name">{{ feature.name }}</h5>
</gl-link>
<div v-if="releaseDate" class="gl-mb-3" data-testid="release-date">{{ releaseDate }}</div>
<div v-if="feature.packages" class="gl-mb-3">
<div v-if="feature.available_in" class="gl-mb-3">
<gl-badge
v-for="packageName in feature.packages"
v-for="packageName in feature.available_in"
:key="packageName"
size="md"
variant="tier"
@ -75,13 +75,16 @@ export default {
{{ packageName }}
</gl-badge>
</div>
<div v-safe-html="feature.body" class="gl-pt-3 gl-line-height-20"></div>
<div
v-safe-html:[$options.safeHtmlConfig]="feature.description"
class="gl-pt-3 gl-line-height-20"
></div>
<gl-button
:href="feature.url"
:href="feature.documentation_link"
target="_blank"
data-track-action="click_whats_new_item"
:data-track-label="feature.title"
:data-track-property="feature.url"
:data-track-label="feature.name"
:data-track-property="feature.documentation_link"
>
{{ __('Learn more') }} <gl-icon name="arrow-right" />
</gl-button>

4
app/models/release_highlight.rb
View File

@ -33,7 +33,7 @@ class ReleaseHighlight
next unless include_item?(item)
begin
item.tap {|i| i['body'] = Banzai.render(i['body'], { project: nil }) }
item.tap {|i| i['description'] = Banzai.render(i['description'], { project: nil }) }
rescue StandardError => e
Gitlab::ErrorTracking.track_exception(e, file_path: file_path)
@ -116,6 +116,6 @@ class ReleaseHighlight
return true unless Gitlab::CurrentSettings.current_application_settings.whats_new_variant_current_tier?
item['packages']&.include?(current_package)
item['available_in']&.include?(current_package)
end
end

40
data/whats_new/202008180001_12_10.yml
View File

@ -1,32 +1,32 @@
---
- title: Create and view requirements in GitLab
body: |
- name: Create and view requirements in GitLab
description: |
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]
url: https://docs.gitlab.com/ee/user/project/requirements/index.html
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/requirements/index.html
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: |
- name: Retrieve CI/CD secrets from HashiCorp Vault
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/index.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/index.html
image_url: https://about.gitlab.com/images/12_10/jwt-vault-1.png
published_at: 2020-04-22
release: 12.10
- title: Epic and Issue Health Tracking
body: |
- name: Epic and Issue Health Tracking
description: |
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.
@ -35,34 +35,34 @@
stage: Plan
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/project/issues/index.html#health-status
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/issues/index.html#health-status
image_url: https://about.gitlab.com/images/12_10/epic-health-status.png
published_at: 2020-04-22
release: 12.10
- title: Import Issues from Jira to GitLab
body: |
- name: Import Issues from Jira to GitLab
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/import/jira.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/import/jira.html
image_url: https://about.gitlab.com/images/12_10/jira-importer.png
published_at: 2020-04-22
release: 12.10
- title: Autoscaling GitLab CI jobs on AWS Fargate
body: |
- name: Autoscaling GitLab CI jobs on AWS Fargate
description: |
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
packages: [Free, Premium, Ultimate]
url: https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/fargate/-/blob/master/docs/README.md
available_in: [Free, Premium, Ultimate]
documentation_link: https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/fargate/-/blob/master/docs/README.md
image_url: https://about.gitlab.com/images/12_9/autoscaling_ci_fargate.png
published_at: 2020-04-22
release: 12.10

40
data/whats_new/202008180002_13_0.yml
View File

@ -1,66 +1,66 @@
---
- title: Gitaly Cluster for High Availability Git Storage
body: |
- name: Gitaly Cluster for High Availability Git Storage
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/administration/gitaly/praefect.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/administration/gitaly/praefect.html
image_url: https://about.gitlab.com/images/13_0/praefect-architecture.png
published_at: 2020-05-22
release: 13.0
- title: Auto Deploy to ECS
body: |
- name: Auto Deploy to ECS
description: |
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: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/topics/autodevops/index.html#aws-ecs
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/topics/autodevops/index.html#aws-ecs
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: |
- name: View Epic Hierarchy on a Roadmap
description: |
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
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/group/roadmap/
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/group/roadmap/
image_url: https://about.gitlab.com/images/13_0/Expand-Epic-Hierarchy-Roadmap_roadmap.png
published_at: 2020-05-22
release: 13.0
- title: Versioned Snippets
body: |
- name: Versioned Snippets
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/snippets.html#versioned-snippets
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/snippets.html#versioned-snippets
image_url: https://about.gitlab.com/images/13_0/phikai-versioned-snippets.png
published_at: 2020-05-22
release: 13.0
- title: Dark Theme in the Web IDE
body: |
- name: Dark Theme in the Web IDE
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/web_ide/#themes
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/web_ide/#themes
image_url: https://about.gitlab.com/images/13_0/phikai-web-ide-dark-theme.png
published_at: 2020-05-22
release: 13.0

32
data/whats_new/202008180003_13_01.yml
View File

@ -1,49 +1,49 @@
---
- title: Manage IT Alerts in GitLab
body: |
- name: Manage IT Alerts in GitLab
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/operations/incident_management/index.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/operations/incident_management/index.html
image_url: https://about.gitlab.com/images/13_1/alert_management.png
published_at: 2020-06-22
release: 13.1
- title: Accessibility testing merge request widget
body: |
- name: Accessibility testing merge request widget
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/merge_requests/accessibility_testing.html#accessibility-merge-request-widget
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/merge_requests/accessibility_testing.html#accessibility-merge-request-widget
image_url: https://about.gitlab.com/images/13_1/a11y-merge-request-widget.png
published_at: 2020-06-22
release: 13.1
- title: Mark any Design Thread as Resolved
body: |
- name: Mark any Design Thread as Resolved
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/issues/design_management.html#resolve-design-threads
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/issues/design_management.html#resolve-design-threads
image_url: https://about.gitlab.com/images/13_1/resolve-design-comment.gif
published_at: 2020-06-22
release: 13.1
- title: Merge request reviews moved to Free
body: |
- name: Merge request reviews moved to Free
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/discussions/index.html#merge-request-reviews
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/discussions/index.html#merge-request-reviews
image_url: https://about.gitlab.com/images/13_1/batch_comments.png
published_at: 2020-06-22
release: 13.1

32
data/whats_new/202008210001_13_02.yml
View File

@ -1,45 +1,45 @@
---
- title: Assign Issues to Iterations
body: |
- name: Assign Issues to Iterations
description: |
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
packages: [Premium, Ultimate]
url: https://www.youtube.com/watch?v=31pNKjenlJY&feature=emb_title
available_in: [Premium, Ultimate]
documentation_link: https://www.youtube.com/watch?v=31pNKjenlJY&feature=emb_title
image_url: https://img.youtube.com/vi/31pNKjenlJY/hqdefault.jpg
published_at: 2020-07-22
release: 13.2
- title: Container Host Monitoring and Blocking
body: |
- name: Container Host Monitoring and Blocking
description: |
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
packages: [Free, Premium, Ultimate]
url: https://www.youtube.com/watch?v=WxBzBz76FxU&feature=youtu.be
available_in: [Free, Premium, Ultimate]
documentation_link: https://www.youtube.com/watch?v=WxBzBz76FxU&feature=youtu.be
image_url: https://img.youtube.com/vi/WxBzBz76FxU/hqdefault.jpg
published_at: 2020-07-22
release: 13.2
- title: Official GitLab-Figma Plugin
body: |
- name: Official GitLab-Figma Plugin
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/issues/design_management.html#gitlab-figma-plugin
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/issues/design_management.html#gitlab-figma-plugin
image_url: https://about.gitlab.com/images/13_2/figma-plugin.png
published_at: 2020-07-22
release: 13.2
- title: Cluster health monitoring now available in Free
body: |
- name: Cluster health monitoring now available in Free
description: |
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 Free.
@ -48,8 +48,8 @@
stage: Monitor
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/clusters/#visualizing-cluster-health
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/clusters/#visualizing-cluster-health
image_url: https://about.gitlab.com/images/13_2/k8s_cluster_monitoring.png
published_at: 2020-07-22
release: 13.2

32
data/whats_new/202009150001_13_03.yml
View File

@ -1,30 +1,30 @@
---
- title: Coverage-guided fuzz testing for Go and C/C++ applications
body: |
- name: Coverage-guided fuzz testing for Go and C/C++ applications
description: |
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
packages: [Ultimate]
url: https://www.youtube.com/watch?v=3wdWMDRLdp4
available_in: [Ultimate]
documentation_link: https://www.youtube.com/watch?v=3wdWMDRLdp4
image_url: https://img.youtube.com/vi/3wdWMDRLdp4/hqdefault.jpg
published_at: 2020-08-22
release: 13.3
- title: Create a matrix of jobs using a simple syntax
body: |
- name: Create a matrix of jobs using a simple syntax
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/yaml/#parallel-matrix-jobs
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/yaml/#parallel-matrix-jobs
image_url: https://about.gitlab.com/images/13_3/cartesian-matrix.png
published_at: 2020-08-22
release: 13.3
- title: On-demand DAST scans
body: |
- name: On-demand DAST scans
description: |
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.
@ -33,21 +33,21 @@
stage: Secure
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/dast/#on-demand-scans
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/dast/#on-demand-scans
image_url: https://about.gitlab.com/images/13_3/dast_on_demand_v13_3.png
published_at: 2020-08-22
release: 13.3
- title: SAST security analyzers available for all
body: |
- name: SAST security analyzers available for all
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/sast/#making-sast-analyzers-available-to-all-gitlab-tiers
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/sast/#making-sast-analyzers-available-to-all-gitlab-tiers
image_url: https://about.gitlab.com/images/13_3/sast-gitlab-languages.png
published_at: 2020-08-22
release: 13.3

40
data/whats_new/202009300001_13_04.yml
View File

@ -1,17 +1,17 @@
---
- title: Use HashiCorp Vault secrets in CI jobs
body: |
- name: Use HashiCorp Vault secrets in CI jobs
description: |
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
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/secrets
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/secrets
image_url: https://about.gitlab.com/images/13_4/vault_ci.png
published_at: 2020-09-22
release: 13.4
- title: Introducing the GitLab Kubernetes Agent
body: |
- name: Introducing the GitLab Kubernetes Agent
description: |
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.
@ -22,26 +22,26 @@
stage: Configure
self-managed: true
gitlab-com: false
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/clusters/agent
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/clusters/agent
image_url: https://about.gitlab.com/images/13_4/gitops-header.png
published_at: 2020-09-22
release: 13.4
- title: Grant users deployment permissions without code access
body: |
- name: Grant users deployment permissions without code access
description: |
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
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/environments/protected_environments.html#environment-access-by-group-membership
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/environments/protected_environments.html#environment-access-by-group-membership
image_url: https://about.gitlab.com/images/13_4/deployer-role.png
published_at: 2020-09-22
release: 13.4
- title: Security Center
body: |
- name: Security Center
description: |
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.
@ -50,21 +50,21 @@
stage: Secure
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/security_dashboard/#instance-security-center
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/security_dashboard/#instance-security-center
image_url: https://about.gitlab.com/images/13_4/instance_vulnerability_report.png
published_at: 2020-09-22
release: 13.4
- title: Quick navigation using the Search bar
body: |
- name: Quick navigation using the Search bar
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/search/#autocomplete-suggestions
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/search/#autocomplete-suggestions
image_url: https://about.gitlab.com/images/13_4/enablement_global_search.gif
published_at: 2020-09-22
release: 13.4

48
data/whats_new/202010230001_13_05.yml
View File

@ -1,6 +1,6 @@
---
- title: Group wikis
body: |
- name: Group wikis
description: |
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.
@ -11,26 +11,26 @@
stage: Create
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/group/index.html#group-wikis
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/group/index.html#group-wikis
image_url: https://about.gitlab.com/images/13_5/cdybenko-group-wiki.png
published_at: 2020-10-22
release: 13.5
- title: Install the GitLab Kubernetes Agent with Omnibus GitLab
body: |
- name: Install the GitLab Kubernetes Agent with Omnibus GitLab
description: |
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
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/clusters/agent/
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/clusters/agent/
image_url: https://about.gitlab.com/images/13_5/gitops-header.png
published_at: 2020-10-22
release: 13.5
- title: Snippets with multiple files
body: |
- name: Snippets with multiple files
description: |
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.
@ -39,47 +39,47 @@
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/snippets.html#multiple-files-by-snippet
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/snippets.html#multiple-files-by-snippet
image_url: https://about.gitlab.com/images/13_5/phikai-snippets-multiple-files.png
published_at: 2020-10-22
release: 13.5
- title: Enable instance-level shared runners when viewing groups
body: |
- name: Enable instance-level shared runners when viewing groups
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/runners/index.html#disable-shared-runners
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/runners/index.html#disable-shared-runners
image_url: https://about.gitlab.com/images/13_5/enable_shared_runners_v2.png
published_at: 2020-10-22
release: 13.5
- title: Feature Flags flexible rollout strategy
body: |
- name: Feature Flags flexible rollout strategy
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/operations/feature_flags.html#percent-rollout
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/operations/feature_flags.html#percent-rollout
image_url: https://about.gitlab.com/images/13_5/percent-rollout.png
published_at: 2020-10-22
release: 13.5
- title: SAST support for iOS and Android mobile apps
body: |
- name: SAST support for iOS and Android mobile apps
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks
image_url: https://about.gitlab.com/images/13_5/sast-gitlab-mobile.png
published_at: 2020-10-22
release: 13.5

40
data/whats_new/202011230001_13_06.yml
View File

@ -1,6 +1,6 @@
---
- title: Auto Deploy to EC2
body: |
- name: Auto Deploy to EC2
description: |
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/).
@ -9,26 +9,26 @@
stage: Release
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/cloud_deployment/#custom-build-job-for-auto-devops
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/cloud_deployment/#custom-build-job-for-auto-devops
image_url: https://img.youtube.com/vi/4B-qSwKnacA/hqdefault.jpg
published_at: 2020-11-22
release: 13.6
- title: Display Code Quality severity ratings
body: |
- name: Display Code Quality severity ratings
description: |
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
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html#code-quality-widget
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html#code-quality-widget
image_url: https://about.gitlab.com/images/13_6/code_quality_severity.png
published_at: 2020-11-22
release: 13.6
- title: Display code coverage data for selected projects
body: |
- name: Display code coverage data for selected projects
description: |
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.
@ -39,13 +39,13 @@
stage: Verify
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/group/repositories_analytics/index.html#latest-project-test-coverage-list
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/group/repositories_analytics/index.html#latest-project-test-coverage-list
image_url: https://about.gitlab.com/images/13_6/display_selected_coverage_projects_example.png
published_at: 2020-11-22
release: 13.6
- title: Group-level management of project integrations
body: |
- name: Group-level management of project integrations
description: |
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.
@ -58,13 +58,13 @@
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/admin_area/settings/project_integration_management.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/admin_area/settings/project_integration_management.html
image_url: https://about.gitlab.com/images/13_6/project-integration-inheriting-settings.png
published_at: 2020-11-22
release: 13.6
- title: Milestone Burnup Charts and historically accurate reporting
body: |
- name: Milestone Burnup Charts and historically accurate reporting
description: |
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.
@ -75,8 +75,8 @@
stage: Plan
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html#burnup-charts
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html#burnup-charts
image_url: https://about.gitlab.com/images/13_6/burnup-chart.png
published_at: 2020-11-22
release: 13.6

32
data/whats_new/202012160001_13_07.yml
View File

@ -1,17 +1,17 @@
---
- title: Auto rollback in case of failure
body: |
- name: Auto rollback in case of failure
description: |
If you have a critical problem with a deployment, manual actions to fix it often take too long and lead to a degradation in production that impacts your users. Now, you can leverage an automatic rollback mechanism that reverts your deployment back to the last successful deployment. Also, when GitLab finds problems in production it automatically notifies you with an alert. This gives you peace of mind and precious development time to debug, investigate, and fix problems without causing downtime.
stage: Release
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/ci/environments/#auto-rollback
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/environments/#auto-rollback
image_url: https://img.youtube.com/vi/G8fYYrxqF5E/hqdefault.jpg
published_at: 2020-12-22
release: 13.7
- title: Reviewers for merge requests
body: |
- name: Reviewers for merge requests
description: |
Asking a colleague to review your code should be a routine part of contributing code, but it's often needlessly complex. A simple task like asking for a review can lead to confusion. For example, how should you ask? An email? Comment? Chat message? Without a formal process, reviews can be inconsistent and hard to keep track of. Previously, an option was to assign a reviewer to a merge request, but even with this formality, both the author and the reviewer appeared in the same assignee field, making it hard for other team members to know who was doing what.
GitLab 13.7 introduces reviewers for merge requests, which allows authors to request a review from someone. The new "Reviewers" field allows users to be designated as reviewers in a similar way to assignees. The reviewers receive a notification inviting them to review the merge request. This provides a formal process for requesting a review and clarifies the roles of each user in a merge request.
@ -20,32 +20,32 @@
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/merge_requests/getting_started#reviewer
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/merge_requests/getting_started#reviewer
image_url: https://about.gitlab.com/images/13_7/reviewers_sidebar.png
published_at: 2020-12-22
release: 13.7
- title: Clone an issue with a quick action
body: |
- name: Clone an issue with a quick action
description: |
To make generating similar issues more efficient, issues now support a `/clone` quick action, which creates a new issue in the same project, with an identical title, description, and metadata. The `/clone` quick action replaces a more cumbersome process, which involves multiple steps to create an issue, copy the ID or path of the source issue, and use the `copy_meta` quick action.
By default, issues are cloned into the same project and do not include system notes and comments, but you can also change the default behavior when cloning.
stage: Plan
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/quick_actions.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/quick_actions.html
image_url: https://about.gitlab.com/images/13_7/clone_issue_with_quick_action.png
published_at: 2020-12-22
release: 13.7
- title: GitLab Runner for Red Hat OpenShift
packages: [Free, Premium, Ultimate]
- name: GitLab Runner for Red Hat OpenShift
available_in: [Free, Premium, Ultimate]
self-managed: true
gitlab-com: true
url: 'https://docs.gitlab.com/runner/install/openshift.html'
documentation_link: 'https://docs.gitlab.com/runner/install/openshift.html'
image_url: 'https://about.gitlab.com/images/13_7/runner-redhat-openshift.png'
stage: Verify
body: |
description: |
Available today is the GitLab Runner container image for the [Red Hat OpenShift Container Platform](https://www.openshift.com/products/container-platform). To install the runner on OpenShift, you can use the new [GitLab Runner Operator](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator) available from the beta channel in Red Hat's Operator Hub - a web console for OpenShift cluster administrators to discover and select Operators to install on their cluster. Operator Hub is deployed by default in the OpenShift Container Platform. We plan to transition the GitLab Runner Operator to the stable channel, and by extension [GA](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/6), in early 2021. Finally, we are also developing an operator for GitLab, so stay tuned to future release posts for those announcements.
published_at: 2020-12-22
release: 13.7

56
data/whats_new/202101140001_13_08.yml
View File

@ -1,82 +1,82 @@
---
- title: Pipeline editor
body: |
- name: Pipeline editor
description: |
GitLab CI/CD provides you with flexible options to support a variety of advanced pipeline use cases. Pipeline syntax can be verbose and sometimes complicated, especially for those who are new to GitLab CI/CD. In this release, we are proud to introduce our first iteration of the Pipeline Editor.
The editor makes the CI configuration authoring experience much easier for both novice and advanced users alike. The pipeline editor is a single solution that groups all the existing CI authoring features (and future ones) in a single location. The pipeline editor is the best place to go when configuring your pipeline.
stage: Verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/pipeline_editor/index.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/pipeline_editor/index.html
image_url: https://img.youtube.com/vi/MQpSyvMpsHA/hqdefault.jpg
published_at: 2021-01-22
release: 13.8
- title: Visualization of pipeline configuration
body: |
- name: Visualization of pipeline configuration
description: |
A complex CI configuration can be difficult to understand as a developer, especially when trying to predict how your pipeline might behave (or misbehave). Without a visual aid, it is challenging to form a mental image of the relationships between all of the jobs and determine how they are interconnected. In our first iteration of a pipeline visualization, you can now see a graphic representation of your `.gitlab-ci.yml` configuration to better understand and predict how your pipelines will perform.
stage: verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/yaml/visualization.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/yaml/visualization.html
image_url: https://about.gitlab.com/images/13_8/pipeline_visual_builder.png
published_at: 2021-01-22
release: 13.8
- title: Deployment frequency charts
packages: [Ultimate]
- name: Deployment frequency charts
available_in: [Ultimate]
self-managed: true
gitlab-com: true
image_url: https://about.gitlab.com/images/13_8/deployment_graph.png
url: https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#deployment-frequency-charts
documentation_link: https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#deployment-frequency-charts
stage: Release
body: |
description: |
Knowing and monitoring deployment frequency is a starting point for organizations adopting DevOps. We are proud to introduce the deployment frequency charts at the project level so that you and your development teams can monitor the efficiency of deployments over time, find bottlenecks, and make improvements when necessary. This is the first of the DORA metrics that we are making available within GitLab out of the box.
published_at: 2021-01-22
release: 13.8
- title: Scope a board to the current iteration
body: |
- name: Scope a board to the current iteration
description: |
Many teams use boards to manage issues during an iteration. In 13.6, we added support for [filtering issues on a board to a specific Iteration](https://gitlab.com/gitlab-org/gitlab/-/issues/118742), but it is cumbersome to remember to apply that filter every time you go to your board. In this release, we've added the ability to scope your board to the currently active iteration.
stage: plan
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/issue_board.html#configurable-issue-boards
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/issue_board.html#configurable-issue-boards
image_url: https://about.gitlab.com/images/13_8/scope_board_to_current_iteration.png
published_at: 2021-01-22
release: 13.8
- title: Download artifacts directly from the merge request widget
body: |
- name: Download artifacts directly from the merge request widget
description: |
We added the ability to download build artifacts directly from the MR widget. This is especially useful for mobile development. An example of this is where users want to test an Android package of a specific build created on a physical device or an emulator. You can now access these artifacts directly from the merge request widget without having to find the artifacts buried in the pipeline view.
stage: Release
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#downloading-artifacts
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#downloading-artifacts
image_url: https://about.gitlab.com/images/13_8/artifact_mr.png
published_at: 2021-01-22
release: 13.8
- title: Rebase quick action for merge requests
body: |
- name: Rebase quick action for merge requests
description: |
Rebase is a Git command used to reapply commits on top of a new commit. In practice, this means reapplying commits from a feature branch on top of the latest version of the target branch (e.g. `main`). In this way, it is possible to bring the feature branch up to date and resolve any conflicts without using a merge commit with the benefit of a simpler linear Git history.
GitLab 13.8 brings the ability to execute the rebase quick action in merge requests, allowing you to quickly invoke the rebase Git utility.
stage: create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/quick_actions.html#quick-actions-for-issues-merge-requests-and-epics
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/quick_actions.html#quick-actions-for-issues-merge-requests-and-epics
image_url: https://about.gitlab.com/images/13_8/rebase_comment.png
published_at: 2021-01-22
release: 13.8
- title: GitLab Pages is now available for Kubernetes deployments of GitLab
body: |
- name: GitLab Pages is now available for Kubernetes deployments of GitLab
description: |
GitLab Pages is a popular static-site hosting service built into GitLab, and we are excited to announce that it is now available for GitLab instances running on Kubernetes. Pages was one of the last remaining feature gaps compared to an Omnibus deployment.
stage: enablement
self-managed: true
gitlab-com: false
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/charts/charts/gitlab/gitlab-pages/index.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/charts/charts/gitlab/gitlab-pages/index.html
image_url: https://about.gitlab.com/images/home/kubernetes.png
published_at: 2021-01-22
release: 13.8

80
data/whats_new/202102180001_13_09.yml
View File

@ -1,77 +1,77 @@
- title: "Select CI/CD configuration from any job and reuse it"
body: |
- name: "Select CI/CD configuration from any job and reuse it"
description: |
Previously, if you wanted to reuse the same configuration in multiple jobs, you had two options: add YAML anchors, which don't work across different configuration files, or use `extends` to reuse an entire section.
In this release, we've added a new YAML function called `!reference`, which lets you target the exact configuration you want to reuse as part of your CI/CD pipeline, even if it's in another file.
stage: Verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/yaml/index.html#reference-tags
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/yaml/index.html#reference-tags
image_url: https://about.gitlab.com/images/13_9/reference.png
published_at: 2021-02-22
release: 13.9
- title: "GPU and smart scheduling support for GitLab Runner"
body: |
- name: "GPU and smart scheduling support for GitLab Runner"
description: |
Specialized compute workloads like those used in machine learning can significantly benefit from access to GPUs. Developers can configure GitLab Runner to leverage GPUs in the Docker executor by forwarding the `--gpu` flag. You can also use this with recent support in [GitLab’s fork of Docker Machine](https://docs.gitlab.com/runner/executors/docker_machine.html#using-the-forked-version-of-docker-machine), which allows you to [accelerate workloads with attached GPUs](https://cloud.google.com/compute/docs/gpus/create-vm-with-gpus). Doing so can help control costs associated with potentially expensive machine configurations.
stage: Verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/runner/executors/docker_machine.html#using-gpus-on-google-compute-engine
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/runner/executors/docker_machine.html#using-gpus-on-google-compute-engine
image_url: https://about.gitlab.com/images/ci/gitlab-ci-cd-logo_2x.png
published_at: 2021-02-22
release: 13.9
- title: "Vault JWT (JSON Web Token) supports GitLab environments"
body: |
- name: "Vault JWT (JSON Web Token) supports GitLab environments"
description: |
To simplify integrations with HashiCorp Vault, we've shipped Vault JWT token support. From the launch, you could restrict access based on data in the JWT. This release gives you a new dimension for restricting access to credentials: the environment a job targets.
This release extends the existing Vault JWT token to support environment-based restrictions too. As the `environment` name could be supplied by the user running the pipeline, we recommend you use the new environment-based restrictions with the already-existing `ref_type` values for maximum security.
stage: Configure
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/index.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/index.html
image_url: https://about.gitlab.com/images/icons/get-a-license.svg
published_at: 2021-02-22
release: 13.9
- title: "SAST Support for .NET 5"
body: |
- name: "SAST Support for .NET 5"
description: |
Microsoft's [release of .NET 5.0](https://docs.microsoft.com/en-us/dotnet/core/dotnet-five) is the next major release of .NET Core which supports more types of apps and more platforms than .NET Core or .NET Framework. We have updated our .NET SAST analyzer, [Security Code Scan](https://security-code-scan.github.io/) to support this new version which is also now supported with [our SAST language detection](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) allowing GitLab SAST to automatically detect .NET 5 projects. This change was part of a community contribution by [@shaun.burns](https://gitlab.com/shaun.burns).
stage: Secure
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#analyzers-data
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#analyzers-data
image_url: https://about.gitlab.com/images/solutions/icon_sheild-check.svg
published_at: 2021-02-22
release: 13.9
- title: "Create Jira issues from Vulnerabilities"
body: |
- name: "Create Jira issues from Vulnerabilities"
description: |
Many customers use Jira as their single source of truth for tracking issues and engineering work. When using GitLab for SCM and CI/CD, they can take advantage of our existing integration to pass information from MRs and commits into existing Jira issues. However, until now there has been no way to automatically pass information about vulnerabilities detected by security scanners into Jira. This leaves users who rely on Jira to track work no choice but to manually copy vulnerability information into new Jira issues.
To address this, we're introducing a new ability to create Jira issues directly from a vulnerability's details. You will see this as a new option in your existing Jira integration settings. Simply enable the new option and select the desired Jira issue type. Available issue types are pulled automatically based on the currently configured Jira target project. Once enabled, all places in your project where you can create GitLab issues from a vulnerability will instead directly create a Jira issue of the configured type.
stage: Secure
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#create-a-gitlab-issue-for-a-vulnerability
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#create-a-gitlab-issue-for-a-vulnerability
image_url: https://about.gitlab.com/images/13_9/jira-vulnerability-integration.png
published_at: 2021-02-22
release: 13.9
- title: "Security Alert Dashboard for Container Network Policy Alerts"
body: |
- name: "Security Alert Dashboard for Container Network Policy Alerts"
description: |
We're pleased to announce the first release of a dashboard for security alerts! Users can now configure Container Network Policies to send alerts to the security alert dashboard. This is especially useful when traffic must be closely monitored but cannot be blocked entirely without negatively impacting the business. You can configure the alerts at **Security & Compliance > Threat Management > Policies**, and view them at **Security & Compliance > Threat Management > Alerts**.
stage: Secure
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/threat_monitoring/#configuring-network-policy-alerts
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/threat_monitoring/#configuring-network-policy-alerts
image_url: https://about.gitlab.com/images/13_9/security_alert_dashboard.png
published_at: 2021-02-22
release: 13.9
- title: "Maintenance Mode"
body: |
- name: "Maintenance Mode"
description: |
Systems administrators occasionally perform maintenance operations on their GitLab instance to keep it performing optimally. Administrators want to offer the highest level of access to their users while these operations are taking place. For example, you may want to perform a [failover test to a secondary site](https://docs.gitlab.com/ee/administration/geo/disaster_recovery/planned_failover.html) as part of the company's business continuity plan. Prior to the failover, you want to pause changes for a short period to ensure the secondary is fully synchronized. Until GitLab 13.8, you could [restrict users from logging in](https://docs.gitlab.com/omnibus/maintenance/#restrict-users-from-logging-into-gitlab), but this would block the entire UI and would render GitLab inaccessible to users.
GitLab 13.9 introduces [maintenance mode](https://docs.gitlab.com/ee/administration/maintenance_mode/index.html), where write operations are disabled at the application level. This means that GitLab is effectively in a read-only state for all non-administrative users (administrators are still able to edit application settings and [background jobs continue](https://docs.gitlab.com/ee/administration/maintenance_mode/index.html#background-jobs)). Regular users are able to log in to GitLab, view the interface and perform other read-only operations, such as `git clone` or `git pull`. Using maintenance mode, systems administrators can perform maintenance operations, such as failing over to a secondary site, with minimal disruption to regular users.
@ -80,43 +80,43 @@
stage: Enablement
self-managed: true
gitlab-com: false
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/administration/maintenance_mode/index.html
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/administration/maintenance_mode/index.html
image_url: https://about.gitlab.com/images/13_9/maintenance_mode.png
published_at: 2021-02-22
release: 13.9
- title: "New merge request metric: mean time to merge"
body: |
- name: "New merge request metric: mean time to merge"
description: |
A new metric, mean time to merge (MTTM), is available in project-level merge request analytics. MTTM is the average time from when a merge request (MR) is created, until the time it is merged. By selecting different dates in the date range selector, you can see how your time to merge MRs changes over time and understand whether you are becoming more efficient at reviewing and merging code.
stage: Manage
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/analytics/merge_request_analytics.html#mean-time-to-merge
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/analytics/merge_request_analytics.html#mean-time-to-merge
image_url: https://about.gitlab.com/images/13_9/mttm.png
published_at: 2021-02-22
release: 13.9
- title: "Filter roadmaps by confidentiality"
body: |
- name: "Filter roadmaps by confidentiality"
description: |
When viewing a roadmap, there used to be no way to hide confidential epics from the main view. This could be frustrating if you wanted to share your roadmap with a public audience. We've updated the search bar filter to include confidentiality so you now have another layer in which you can refine your roadmap.
stage: Plan
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/group/roadmap/#sort-and-filter-the-roadmap
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/group/roadmap/#sort-and-filter-the-roadmap
image_url: https://about.gitlab.com/images/13_9/roadmap-filter-by-confidentiality.png
published_at: 2021-02-22
release: 13.9
- title: "Allow Deploy Keys to push to protected branches"
body: |
- name: "Allow Deploy Keys to push to protected branches"
description: |
Prior to GitLab 12.0, deploy keys with write access could push commits to protected branches. Support for this was removed due to security concerns, but many users still requested it, as they used deploy keys to ensure that only users with deploy keys could push to their repositories. Removing deploy keys also eliminates the need to use a service user or machine user, which ties up a license for any team that wants to allow deploy keys to push to protected branches just for this use case.
We are excited to announce that we resolved this issue and now deploy keys can push to protected branches once more while abiding by security best practices. By moving towards an isolated permission model for deploy keys, users can now select deploy keys to link to protected branches directly from the **Settings** page on protected branches.
stage: Release
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/protected_branches.html#allow-deploy-keys-to-push-to-a-protected-branch
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/protected_branches.html#allow-deploy-keys-to-push-to-a-protected-branch
image_url: https://about.gitlab.com/images/13_9/deploy_keys.png
published_at: 2021-02-22
release: 13.9

56
data/whats_new/202103220001_13_10.yml
View File

@ -1,16 +1,16 @@
- title: "GitLab Runner for Red Hat OpenShift GA"
body: |
- name: "GitLab Runner for Red Hat OpenShift GA"
description: |
The GitLab Runner Operator is generally available in the [Red Hat OpenShift Container Platform](https://www.openshift.com/products/container-platform). To install GitLab Runner on OpenShift, you can use the [GitLab Runner Operator](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator), which is available from the stable channel in the OperatorHub. The Container Platform is a web console for OpenShift cluster administrators to discover and select Operators to install on their cluster. We are also developing an [Operator](https://gitlab.com/groups/gitlab-org/-/epics/3444) for GitLab, so stay tuned to future release posts for those announcements.
stage: Verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/runner/install/openshift.html
available_in: [Free, Premium, Ultimate]
documentation_link: 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)"
body: |
- name: "View epics on a board (MVC)"
description: |
If you work on epics in GitLab, it can be tough to visualize your epics' workflow status. Often, when drafting or writing epics, you might want to use labels (like `Open`, `Doing`, or `Done`) to keep tabs on the next steps when creating your project plan.
In this release, we took our awesome [Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.html) feature and optimized it for viewing epics. You can now visualize the workflow status of your epics on an epic board by applying [labels](https://docs.gitlab.com/ee/user/project/labels.html#label-management) or [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) to them.
@ -19,13 +19,13 @@
stage: Plan
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/group/epics/epic_boards.html
available_in: [Premium, Ultimate]
documentation_link: 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
published_at: 2021-03-22
release: 13.10
- title: "View Jira issue details in GitLab"
body: |
- name: "View Jira issue details in GitLab"
description: |
Users of our Jira issue list feature can now view the details of an issue directly inside of GitLab! This MVC enables developers to see the details, labels, and comments on an issue, giving them the ability to stay in GitLab while working on Jira issues.
Our goal is to empower developers to _stay inside of GitLab_ during the majority of their day, and this is now one less trip to Jira you'll have to make.
@ -34,48 +34,48 @@
stage: Create
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/integrations/jira.html#view-a-jira-issue
available_in: [Premium, Ultimate]
documentation_link: 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"
body: |
- name: "DORA4-based lead time for changes"
description: |
Measuring the efficiency of your software development lifecycle is an important step to grow DevOps adoption for any organization. In the previous milestone, we added support for [DORA4-based Deployment Frequency](https://docs.gitlab.com/ee/api/dora4_project_analytics.html). In this release, we are excited to announce the support of a new API for lead time for changes (via merge requests) on the project level. The lead time for changes gives you an indication of how long it takes for code to be committed and deployed to your production environment. Understanding and tracking this data is a great starting point in your journey to continuous improvement in your DevOps process.
stage: Release
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
available_in: [Ultimate]
documentation_link: 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"
body: |
- name: "Create a release from an existing tag"
description: |
Previously, creating a release was supported only for new tags. In GitLab 13.10, you can now create a release by selecting an existing tag, something that will give you more flexibility when planning releases.
stage: Release
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/releases/#create-a-release
available_in: [Free, Premium, Ultimate]
documentation_link: 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"
body: |
- name: "Integrate any IT alerting tool with GitLab"
description: |
Alert integrations are a critical part of your Incident Management workflows. It's difficult to manage integrations between tools, especially when several monitoring tools like Nagios, Solarwinds, etc. alert on your services. These integrations notify you and your team of incidents, so it's critical for them to be easy to set up and maintain.
In this version of GitLab, you can create multiple HTTP endpoints with unique auth tokens for each integrated monitoring tool. When you set up an HTTP endpoint with a unique auth token for each monitoring tool, your team can manage each tool separately without affecting alerts from other tools nor take down all of your alerting by resetting a single auth token!
stage: Monitor
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/operations/incident_management/integrations.html#http-endpoints
available_in: [Premium, Ultimate]
documentation_link: 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"
body: |
- name: "Merge request test summary usability improvements"
description: |
Increasing the number of tests or custom metrics in a pipeline gives you additional confidence and information. However, increasing these to a large number has also come with a degraded visual experience of the merge request page. The merge request test summary widget has been improved so you can better differentiate between the different test jobs in the widget, making it easier to identify which job contains failed tests.
It has also been challenging to understand why a `junit.xml` file was not parsed without errors being presented. Now you can see parsing errors in the Test Summary widget, as well as the Unit Test report, to identify and resolve structural issues and see test results in GitLab.
@ -84,8 +84,8 @@
stage: Verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/unit_test_reports.html
available_in: [Free, Premium, Ultimate]
documentation_link: 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

72
data/whats_new/202104220001_13_11.yml
View File

@ -1,18 +1,18 @@
- title: GitLab Kubernetes Agent available on GitLab.com
body: |
- name: GitLab Kubernetes Agent available on GitLab.com
description: |
The GitLab Kubernetes Agent is finally available on GitLab.com. By using the Agent, you can benefit from fast, pull-based deployments to your cluster, while GitLab.com manages the necessary server-side components of the Agent. The GitLab Kubernetes Agent is the core building block of GitLab's Kubernetes integrations. The Agent-based integration today supports pull-based deployments and Network Security policy integration and alerts, and will soon receive support for push-based deployments too.
Unlike the legacy, certificate-based Kubernetes integration, the GitLab Kubernetes Agent does not require opening up your cluster towards GitLab and allows fine-tuned RBAC controls around GitLab's capabilities within your clusters.
stage: Configure
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/clusters/agent/
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/clusters/agent/
image_url: https://img.youtube.com/vi/4Sh5bghbAjY/hqdefault.jpg
published_at: 2021-04-22
release: 13.11
- title: Compliance pipeline configurations
body: |
- name: Compliance pipeline configurations
description: |
We are thrilled to announce that it is now possible to define enforceable pipelines that will run for any project assigned a corresponding [compliance framework](https://docs.gitlab.com/ee/user/project/settings/#compliance-framework).
For teams looking to implement compliance requirements in the pipeline workflow, they can now enforce even more separation of duties by setting up a single pipeline definition for a specific compliance framework. All projects using that framework will include the predefined pipeline automatically. Users extend, but cannot modify, the pipeline configuration in the downstream projects, ensuring that compliance steps are run the same way every time.
@ -23,48 +23,48 @@
stage: Manage
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/project/settings/#compliance-pipeline-configuration
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/settings/#compliance-pipeline-configuration
image_url: https://img.youtube.com/vi/upLJ_equomw/hqdefault.jpg
published_at: 2021-04-22
release: 13.11
- title: On-call schedule management
body: |
- name: On-call schedule management
description: |
Software services do not get "turned off" at the end of the business day. Your customers expect 24/7 availability. When things go wrong, you need a team (or multiple teams!) that can quickly and effectively respond to service outages.
Being on-call can be a stressful job. To better manage stress and burn-out, most teams rotate this on-call responsibility. GitLab's **on-call schedule management** allows you and your team to create and manage schedules for on-call responsibilities. Alerts received in GitLab through an HTTP endpoint are routed to the on-call engineer in the schedule for that specific project.
stage: Monitor
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/operations/incident_management/oncall_schedules.html
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/operations/incident_management/oncall_schedules.html
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
body: |
- name: Use multiple caches in the same job
description: |
GitLab CI/CD provides a caching mechanism that saves precious development time when your jobs are running. Previously, it was impossible to configure multiple cache keys in the same job. This limitation may have caused you to use artifacts for caching, or use duplicate jobs with different cache paths. In this release, we provide the ability to configure multiple cache keys in a single job which will help you increase your pipeline performance.
stage: Verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/yaml/index.html#multiple-caches
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/yaml/index.html#multiple-caches
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
body: |
- name: Group SAML Enforcement for Git activity
description: |
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]
url: https://docs.gitlab.com/ee/user/group/saml_sso/#sso-enforcement
available_in: [Premium, Ultimate]
documentation_link: 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
body: |
- name: Cherry pick commits from fork to parent
description: |
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.
Your community of contributors can contribute to your project, and your team no longer needs to manually download a fork's `.patch` file to pull in good changes from stale or unmaintained forks.
@ -73,24 +73,24 @@
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/merge_requests/cherry_pick_changes.html#cherry-pick-into-a-project
available_in: [Free, Premium, Ultimate]
documentation_link: 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
published_at: 2021-04-22
release: 13.11
- title: Improvements to Jira Connect application configuration
body: |
- name: Improvements to Jira Connect application configuration
description: |
When configuring the [GitLab.com for Jira](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud) application, you can now filter the available namespaces when linking them to your account, simplifying configuration for users with access to a large number of namespaces.
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/integration/jira/connect-app.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/integration/jira/connect-app.html
image_url: https://about.gitlab.com/images/13_11/jira-connect-app-search.png
published_at: 2021-04-22
release: 13.11
- title: Search within a settings page
body: |
- name: Search within a settings page
description: |
Finding the exact location of a GitLab setting can be challenging. Even if you know generally where to look, many of the settings views have multiple sections and dozens of individual configuration options.
In this release, you can now use the search field in group, project, admin, and user settings to quickly pinpoint your desired configuration. Your search criteria will filter the current page down to display only relevant settings and even highlight occurrences of your search term on the page.
@ -99,19 +99,19 @@
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/search/#search-settings
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/search/#search-settings
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)
body: |
- name: Deploy GitLab on OpenShift and Kubernetes with the GitLab Operator (beta)
description: |
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
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://gitlab.com/gitlab-org/gl-openshift/gitlab-operator/-/tree/master/doc
available_in: [Free, Premium, Ultimate]
documentation_link: https://gitlab.com/gitlab-org/gl-openshift/gitlab-operator/-/tree/master/doc
image_url: https://about.gitlab.com/images/13_11/gitlab-operator.png
published_at: 2021-04-22
release: 13.11

80
data/whats_new/202105220001_13_12.yml
View File

@ -1,31 +1,31 @@
- title: On-demand DAST GA launch
body: |
- name: On-demand DAST GA launch
description: |
After months of work, we are pleased to announce that our on-demand DAST scanning has reached a General Availability (GA) maturity level. It is ready for usage by anyone who needs to scan an already-deployed application or API outside of a CI/CD pipeline job. With the 13.11 release, we added to on-demand DAST Site profiles the ability to specify authentication information, exclude URLs, add additional request headers, and switch between scanning web applications and APIs. This is in addition to the ability to save scans for quick reusability that was added in 13.9, and the ability to select the branch that a scan is associated with that was added in 13.10. We believe this feature set meets the needs of a majority of GitLab customers.
As we continue to add features, such as scan scheduling, we expect on-demand DAST scanning to cover an ever-increasing range of use cases. As always, we would love as much feedback about these features as possible. Please let us know how things are working for you by leaving a comment in [issue 327396](https://gitlab.com/gitlab-org/gitlab/-/issues/327396).
stage: secure
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/dast/#on-demand-scans
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/dast/#on-demand-scans
image_url: https://about.gitlab.com/images/13_12/dast_on_demand_auth.png
published_at: 2021-05-22
release: 13.12
- title: Filter Project Vulnerability Report by vendor name
body: |
- name: Filter Project Vulnerability Report by vendor name
description: |
GitLab strives to play well with others and security is no exception. We provide many security scanners as part of our Secure offering. We also encourage 3rd party vendors to [integrate their scanning tools](https://docs.gitlab.com/ee/development/integrations/secure.html) using our open API and data interchange formats. A benefit of using GitLab is managing vulnerabilities from multiple scanners in a unified experience. While you were already able to filter by scanner type (SAST, DAST), it wasn't possible to drill down by the tool provider.
You now have even more granularity when managing vulnerabilities with the new ability to filter by scanner and vendor. You can look at all results across a single vendor's scanners or gain confidence in findings from one scan type (e.g. SAST) that are confirmed by both GitLab and the 3rd party tool. The new filtering capability is available now in Project Vulnerability Reports.
stage: secure
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/security_dashboard/#vulnerability-report
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/security_dashboard/#vulnerability-report
image_url: https://about.gitlab.com/images/13_12/select_scanner_by_vendor.png
published_at: 2021-05-22
release: 13.12
- title: Lock latest pipeline artifact to prevent deletion
body: |
- name: Lock latest pipeline artifact to prevent deletion
description: |
GitLab now automatically locks the latest artifact produced from a successful pipeline on any active branch, merge request, or tag to prevent it from being deleted based on expiration if it is still the most recent artifact.
This makes it easier to set a more aggressive expiration policy to clean up older artifacts, helps reduce disk space consumption, and ensures you have always got a copy of the latest artifact from your pipeline.
@ -34,13 +34,13 @@
stage: verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/yaml/index.html#artifactsexpire_in
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/yaml/index.html#artifactsexpire_in
image_url: https://about.gitlab.com/images/growth/verify.png
published_at: 2021-05-22
release: 13.12
- title: Delete associated package files via API
body: |
- name: Delete associated package files via API
description: |
You use the GitLab Package Registry to publish, install, and share your dependencies. You may do this using a variety of package manager formats, such as Maven or npm. If you do this as part of your CI workflow, you may publish many packages to your registry. When you publish a dependency, it generates several files including the package archive.
Prior to GitLab 13.12, GitLab didn't provide a way to delete the files from a package. You could only delete the package itself. These extra files can clutter the user interface or result in someone installing an incorrect or outdated dependency.
@ -49,79 +49,79 @@
stage: package
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/api/packages.html#delete-a-package-file
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/api/packages.html#delete-a-package-file
image_url: https://about.gitlab.com/images/growth/package.png
published_at: 2021-05-22
release: 13.12
- title: Configuration tool for Secret Detection
body: |
- name: Configuration tool for Secret Detection
description: |
Following in the footsteps of the [GitLab SAST configuration tool](https://docs.gitlab.com/ee/user/application_security/sast/index.html#configure-sast-in-the-ui) we are adding support for Secret Detection on the Security Configuration page. We believe that [security is a team effort](https://about.gitlab.com/direction/secure/#security-is-a-team-effort) and this configuration experience makes it easier for non-CI experts to get started with [GitLab Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/). The tool helps a user create a merge request to enable Secret Detection scanning while leveraging best configuration practices like using the GitLab-managed [`SAST.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml). The Configuration tool can create a new `.gitlab-ci.yml` file if one does not exist or update existing simple GitLab CI files, allowing the tool to be used with projects that already have GitLab CI setup.
stage: secure
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/configuration/
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/configuration/
image_url: https://about.gitlab.com/images/13_12/secret_config_button_13_12.png
published_at: 2021-05-22
release: 13.12
- title: Code quality violation notices in MR diffs
body: |
- name: Code quality violation notices in MR diffs
description: |
During code reviews, you may have wanted to highlight Code Quality violations and how to resolve them. Previously, this involved having a browser window open to see the violations on the Merge Request summary and another window reviewing the changes in the MR or your IDE. You may have found switching between them too difficult and given up.
Now, you can see if the file you are reviewing has new code quality violations that are part of the changes right in the Merge Request diff view. This gives you the necessary context to suggest a fix as part of your normal workflow within GitLab without having to keep additional windows open and context switch back and forth between them.
stage: verify
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html#code-quality-in-diff-view
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html#code-quality-in-diff-view
image_url: https://about.gitlab.com/images/13_12/code-quality-mr-diff-mvc.png
published_at: 2021-05-22
release: 13.12
- title: Group-level deployment frequency CI/CD chart
body: |
- name: Group-level deployment frequency CI/CD chart
description: |
As part of our efforts to natively support [DORA4 metrics](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#devops-research-and-assessment-dora-key-metrics) in GitLab, the group-level deployment frequency chart is now available. This chart will show the aggregated deployment frequency metrics for all the projects that are part of the group, and allow you to get a full picture of the deployment frequency across multiple projects and teams, so that you can comprehend their efficiency more accurately. Monitoring deployment frequency helps you understand the efficiency of your deployments over time, find bottlenecks, and focus on improvement areas that span across your projects and teams.
stage: Release
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#deployment-frequency-charts
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#deployment-frequency-charts
image_url: https://about.gitlab.com/images/13_12/group_deployment_frequency.png
published_at: 2021-05-22
release: 13.12
- title: Enforce delayed project removal for all subgroups
body: |
- name: Enforce delayed project removal for all subgroups
description: |
Group owners can now enable and enforce [delayed project removal](https://docs.gitlab.com/ee/user/group/#enable-delayed-project-removal) for all subgroups and projects in their group. Delayed project removal protects your data by placing deleted projects in a read-only state after deletion and can be restored, if required. We plan to expand our settings model and allow more settings to be inherited and enforced in subgroups and projects in future milestones. Our new settings management model gives group owners a way to ensure that their subgroups and projects settings adhere to their organization's security and compliance needs.
stage: manage
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/group/#enable-delayed-project-removal
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/group/#enable-delayed-project-removal
image_url: https://about.gitlab.com/images/13_12/mushakov_delayed_deletion.png
published_at: 2021-05-22
release: 13.12
- title: Mobile application binary scanning support
body: |
- name: Mobile application binary scanning support
description: |
Since GitLab 13.6, we've offered [SAST for Android and iOS mobile projects](https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/#sast-support-for-ios-and-android-mobile-apps). Initially our Mobile App SAST supported the automatic detection of Xcode projects and Android manifest files. With this release and contribution from community contributor [@proletarius101](https://gitlab.com/proletarius101), GitLab SAST now also supports the automatic detection of .ipa (iOS) and .apk (Android) binary files enabling the security scanning of fully built mobile application artifacts. This offers mobile teams more flexibility with how they build and scan their mobile projects with GitLab SAST for security vulnerabilities.
Please note that mobile application scanning is still an experimental feature and [requires enabling the experimental flag](https://docs.gitlab.com/ee/user/application_security/sast/#experimental-features) in your CI template. We will make the mobile application scanner generally available without this flag [in the near future](https://gitlab.com/groups/gitlab-org/-/epics/5977).
stage: secure
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks
image_url: https://about.gitlab.com/images/growth/verify.png
published_at: 2021-05-22
release: 13.12
- title: Instance-level Federated Learning of Cohorts (FLoC) opt-in
body: |
- name: Instance-level Federated Learning of Cohorts (FLoC) opt-in
description: |
[Federated Learning of Cohorts (FLoC)](https://en.wikipedia.org/wiki/Federated_Learning_of_Cohorts) is a new type of web tracking, intended to replace the use of third-party cookies. It does this by grouping users into cohorts based on their browsing history, for the primary purpose of interest-based advertising. FLoC is being activated in the Chrome browser in some regions.
With GitLab 13.12, FLoC will not incorporate GitLab browsing activity by default. If an instance administrator would like their users' GitLab instance usage to contribute to FLoC, they can re-enable in instance settings.
stage: enablement
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/admin_area/settings/floc.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/admin_area/settings/floc.html
image_url: https://about.gitlab.com/images/growth/enablement.png
published_at: 2021-05-22
release: 13.12

96
data/whats_new/202106220001_14_0.yml
View File

@ -1,29 +1,29 @@
- title: Streamlined top navigation menu
body: |
- name: Streamlined top navigation menu
description: |
GitLab 14.0 introduces an all-new, streamlined top navigation menu to help you get where you're going faster and with fewer clicks. This new, consolidated menu offers the combined functionality of the previous Projects, Groups, and More menus. It gives you access to your projects, groups, and instance-level features with a single click. Additionally, all-new responsive views improve the navigation experience on smaller screens.
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://gitlab.com/gitlab-org/gitlab/-/issues/332635
available_in: [Free, Premium, Ultimate]
documentation_link: https://gitlab.com/gitlab-org/gitlab/-/issues/332635
image_url: https://about.gitlab.com/images/14_0/consolidated-top-nav.png
published_at: 2021-06-22
release: 14.0
- title: Sidebar navigation redesign
body: |
- name: Sidebar navigation redesign
description: |
GitLab is big. And it's getting bigger. As we've introduced new features and categories, navigating the densely-packed left sidebar has become less intuitive.
In GitLab 14.0 we've redesigned and restructured the left sidebar for improved usability, consistency, and discoverability. We've moved some links to features around, split up features in the **Operations** menu into three distinct menus, improved visual contrast, and optimized spacing so all the menu items can fit comfortably on a smaller screen. These changes are intended to better match your mental model of the DevOps lifecycle, and provide a more predictable and consistent experience while navigating within your projects and groups.
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://gitlab.com/gitlab-org/gitlab/-/issues/332635
available_in: [Free, Premium, Ultimate]
documentation_link: https://gitlab.com/gitlab-org/gitlab/-/issues/332635
image_url: https://about.gitlab.com/images/14_0/redesigned-left-sidebar.png
published_at: 2021-06-22
release: 14.0
- title: Merge request reviews in VS Code
body: |
- name: Merge request reviews in VS Code
description: |
As a developer, you often spend a majority of your time working in your local development environment. When you're assigned a merge request for review, this requires you to leave your editor and perform that review inside of GitLab. While performing your review inside GitLab, you might also need to use your local editor to gain more context on the proposed changes.
[GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) version `3.21.0` for Visual Studio Code (VS Code) now supports the complete merge request review process, including threads. Select the GitLab icon in VS Code to open the [sidebar](https://gitlab.com/gitlab-org/gitlab-vscode-extension#sidebar-details) to display **Merge requests I'm reviewing**. Select a merge request overview to view the complete details and discussions of the merge request.
@ -34,26 +34,26 @@
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md
available_in: [Free, Premium, Ultimate]
documentation_link: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md
image_url: https://img.youtube.com/vi/F5ypjlOZ4-0/hqdefault.jpg
published_at: 2021-06-22
release: 14.0
- title: Track usage of Code Owners
body: |
- name: Track usage of Code Owners
description: |
Code Owners are an important piece of the code review process in GitLab. When code owners are clearly identified, contributors can see who should review contributions to a file or repository. The Code Owners feature can also be used to establish a merge request approval process. Now, you can track which teams across your organization are using the Code Owners feature in their development workflow.
If you would like to drive adoption of Code Owners, sort the DevOps Adoption table by the Code Owners column to find teams that haven't yet adopted the feature so you can easily identify which teams need help getting started. Alternatively, find teams that have successfully configured Code Owners and get tips and feedback. The DevOps Adoption table is available at [the group level](https://docs.gitlab.com/ee/user/group/devops_adoption/) and [the instance level](https://docs.gitlab.com/ee/user/admin_area/analytics/dev_ops_report.html#devops-adoption).
stage: Manage
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/admin_area/analytics/dev_ops_report#devops-adoption
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/admin_area/analytics/dev_ops_report#devops-adoption
image_url: https://about.gitlab.com/images/14_0/codeownersadoption.png
published_at: 2021-06-22
release: 14.0
- title: Set pronouns on GitLab user profiles
body: |
- name: Set pronouns on GitLab user profiles
description: |
Pronouns have been added to GitLab user profiles. The pronouns appear next to user names in the **Profile** tab. You can:
- Decide whether or not to add pronouns to your profile.
@ -63,24 +63,24 @@
stage: Manage
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/profile/#add-your-gender-pronouns
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/profile/#add-your-gender-pronouns
image_url: https://about.gitlab.com/images/14_0/pronouns.png
published_at: 2021-06-22
release: 14.0
- title: Container Scanning Integration with Trivy
body: |
- name: Container Scanning Integration with Trivy
description: |
Container scanning in GitLab now uses the Trivy engine by default. This change provides customers with more timely vulnerability intelligence updates, more accurate results, and support for a larger number of operating systems. Users who run container scanning with default settings are switched seamlessly and automatically to the new engine in GitLab 14.0. Users who customize the variables in their container scanning job should review our [migration guide](https://docs.gitlab.com/ee/user/application_security/container_scanning/#change-scanners) and make any necessary updates.
stage: Protect
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/container_scanning
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/container_scanning
image_url: https://about.gitlab.com/images/14_0/trivy_scanning_engine.png
published_at: 2021-06-22
release: 14.0
- title: Aggregate identical DAST vulnerabilities into a single vulnerability
body: |
- name: Aggregate identical DAST vulnerabilities into a single vulnerability
description: |
In GitLab 13.12 and earlier, all DAST vulnerabilities found in a scan were listed individually for each URL the vulnerability was found on. This could create many vulnerabilities when the fix was a single file or configuration change. For example: an issue with a server header sent with every HTTP response would be reported on every page on the site, rather than reported as a single issue with multiple occurrences.
To reduce the overhead of managing vulnerabilities, GitLab combines identical vulnerabilities found on multiple pages into a single reported vulnerability in the DAST report. The vulnerability details include a list of all the URLs where the vulnerability was found, rather than individual vulnerabilities being created in the vulnerability list and dashboard for each page.
@ -89,26 +89,26 @@
stage: Secure
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/dast/#reports
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/dast/#reports
image_url: https://about.gitlab.com/images/14_0/dast_aggregated_urls.png
published_at: 2021-06-22
release: 14.0
- title: Epic Boards
body: |
- name: Epic Boards
description: |
Epic Boards align teams and organizations by communicating the status of epics continuously. Previous versions of GitLab required you to view and sort epics in a list to view the overall status. Keeping epics up to date meant making most changes through an epic's detail page. Epic Boards enable you to visualize and refine all of your epics in one place, using a customizable, drag-and-drop interface that is easy for any teammate to understand and collaborate.
Epic Boards are also a game-changer for managing and visualizing ideal epic workflows, such as authoring workflow states (Draft, Writing, Done), DevOps workflow states (such as Planned, In Development, and In Production), or any other mutually exclusive states you might model with scoped labels. Visualizing workflows with an Epic Board empowers you to increase predictability and efficiency.
stage: Plan
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/group/epics/epic_boards.html
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/group/epics/epic_boards.html
image_url: https://about.gitlab.com/images/14_0/epic-boards.png
published_at: 2021-06-22
release: 14.0
- title: Edit wiki pages with the WYSIWYG Markdown editor
body: |
- name: Edit wiki pages with the WYSIWYG Markdown editor
description: |
Editing wiki content could be so much easier! Many GitLab wikis use Markdown formatting, and for some users, Markdown is a barrier to efficient collaboration. In this release, you now have access to a rich, modern Markdown editing experience in your wiki, so you can edit with confidence.
Instant feedback and visual editing tools help make wiki editing more intuitive, and remove barriers to collaboration. GitLab saves the changes as Markdown when you're done, so users who want to edit the Markdown directly can do so. You can even type Markdown into the new editor and it will automatically format the text as you type.
@ -117,45 +117,45 @@
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/wiki/#content-editor
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/wiki/#content-editor
image_url: https://about.gitlab.com/images/14_0/wiki-content-editor-demo.gif
published_at: 2021-06-22
release: 14.0
- title: Change an issue's type
body: |
- name: Change an issue's type
description: |
In some cases, you may wish to change an issue's type. For example, you may want to escalate an issue to an [incident](https://docs.gitlab.com/ee/operations/incident_management/index.html) to ensure that your team handles the problem properly. To change an issue's type, edit the issue and select an issue type from the **Issue type** selector menu.
stage: Monitor
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#change-the-issue-type
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#change-the-issue-type
image_url: https://about.gitlab.com/images/14_0/change_type_on_issues.png
published_at: 2021-06-22
release: 14.0
- title: Prepopulate the CI/CD pipeline editor with an initial template
body: |
- name: Prepopulate the CI/CD pipeline editor with an initial template
description: |
The pipeline editor in GitLab is your one-stop shop when interacting with CI/CD pipelines. Previously, when writing your first pipeline with the editor, you were presented with a blank configuration. While perfectly useful for experienced pipeline authors, it was a bit of a leap for those just starting out.
In this release, if a project does not have a pipeline configured, the editor preloads a template showing an example 3-stage pipeline. You can save and run this pipeline right away to see it in action in your project. On top of that, it also has comments that help you understand the syntax, and tips and hints to help you start customizing the template to match your needs. It is now much easier to get your first green pipeline!
stage: Verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/pipeline_editor/
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/pipeline_editor/
image_url: https://about.gitlab.com/images/14_0/template.png
published_at: 2021-06-22
release: 14.0
- title: Terraform module registry built into GitLab
body: |
- name: Terraform module registry built into GitLab
description: |
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
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/packages/terraform_module_registry/index.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/packages/terraform_module_registry/index.html
image_url: https://about.gitlab.com/images/14_0/terraform-module-registry.png
published_at: 2021-06-22
release: 14.0

80
data/whats_new/202107220001_14_1.yml
View File

@ -1,28 +1,28 @@
- title: Track progress on overall DevOps adoption
body: |
- name: Track progress on overall DevOps adoption
description: |
See the total number of key DevOps features adopted across your organization using the new progress bars in DevOps Adoption. Progress bars help you understand the value that teams are getting from GitLab and evaluate the state of your DevOps transformation.
stage: Manage
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/group/devops_adoption/
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/group/devops_adoption/
image_url: https://about.gitlab.com/images/14_1/progressbar.png
published_at: 2021-07-22
release: 14.1
- title: Track use of security scanning across multiple teams
body: |
- name: Track use of security scanning across multiple teams
description: |
Track which groups across your organization have enabled SAST and DAST scanning. This is helpful for verifying compliance with organizational requirements, responding to audit requests, and tracking progress on company initiatives to make applications more secure. To track adoption, go to the **Sec** tab in DevOps Adoption either at the group level or instance level.
To see groups that have enabled fuzz testing and dependency scanning, use [the DevOps API](https://docs.gitlab.com/ee/api/graphql/reference/index.html#devopsadoptionsnapshot). Fuzz testing and dependency scanning will be added to the DevOps Adoption UI in an upcoming release.
stage: Manage
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/group/devops_adoption
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/group/devops_adoption
image_url: https://about.gitlab.com/images/14_1/scanadoption.png
published_at: 2021-07-22
release: 14.1
- title: Create and apply patches in VS Code
body: |
- name: Create and apply patches in VS Code
description: |
When reviewing a merge request (MR) it can be helpful to make suggestions to many of the changed files. This is often done by creating a patch file with the suggestions and sharing it with others. The problem is that this requires several manual steps like running Git commands and uploading the patch file somewhere others can download it.
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).
@ -33,37 +33,37 @@
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md#create-and-apply-snippet-patch'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md#create-and-apply-snippet-patch'
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
body: |
- name: Code coverage merge request approval rule
description: |
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.
Now you can enforce this organizational policy with the new Coverage check approval rule. This is a simple way to ensure merge requests that would decrease test coverage cannot be merged.
stage: Verify
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/ci/pipelines/settings.html#coverage-check-approval-rule'
available_in: [Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/ci/pipelines/settings.html#coverage-check-approval-rule'
image_url: https://about.gitlab.com/images/14_1/coverage-mr-approval-rule.png
published_at: 2021-07-22
release: 14.1
- title: Registration Features
body: |
- name: Registration Features
description: |
[Registration Features](https://docs.gitlab.com/ee/development/service_ping/index.html#registration-features-program) introduces the ability for free, self-managed users running GitLab EE to access paid features by registering with GitLab and sharing activity data via [Service Ping](https://docs.gitlab.com/ee/development/service_ping/index.html#what-is-service-ping). The first feature introduced is [email from GitLab](https://docs.gitlab.com/ee/tools/email.html), enabling instance administrators to email users within their instance.
stage: Growth
self-managed: true
gitlab-com: false
packages: [Free]
url: 'https://docs.gitlab.com/ee/development/service_ping/index.html#registration-features-program'
available_in: [Free]
documentation_link: 'https://docs.gitlab.com/ee/development/service_ping/index.html#registration-features-program'
image_url: https://about.gitlab.com/images/14_1/registration-features.png
published_at: 2021-07-22
release: 14.1
- title: Build, publish, and share Helm charts
body: |
- name: Build, publish, and share Helm charts
description: |
Helm defines a [chart](https://helm.sh/docs/intro/using_helm/#three-big-concepts) as a Helm package that contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. For organizations that create and manage their own Helm charts, it's important to have a central repository to collect and share them.
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!
@ -72,26 +72,26 @@
stage: Package
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/packages/helm_repository/
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/packages/helm_repository/
image_url: https://img.youtube.com/vi/B6K373-pAgw/hqdefault.jpg
published_at: 2021-07-22
release: 14.1
- title: Escalation Policies
body: |
- name: Escalation Policies
description: |
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.
stage: Monitor
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/operations/incident_management/escalation_policies.html
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/operations/incident_management/escalation_policies.html
image_url: https://img.youtube.com/vi/-1MuKzWJXKQ/hqdefault.jpg
published_at: 2021-07-22
release: 14.1
- title: CI/CD workflow for Kubernetes clusters
body: |
- name: CI/CD workflow for Kubernetes clusters
description: |
Until now, connecting Kubernetes clusters to GitLab CI/CD required you to open up your clusters towards GitLab. Some organizations do not encourage opening up their firewall externally due to security concerns.
GitLab now ships with a CI/CD functionality that connects runners with your Kubernetes cluster by using the [GitLab agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/). This enables versatile GitOps workflows where the deployment logic can be coded in the pipeline.
@ -104,13 +104,13 @@
stage: Configure
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html
image_url: https://img.youtube.com/vi/eXxM4ScqiJs/hqdefault.jpg
published_at: 2021-07-22
release: 14.1
- title: External status checks for merge requests
body: |
- name: External status checks for merge requests
description: |
You can now contact an external API to perform a status check in a merge request. This is a great way to integrate GitLab with third-party systems that:
- Run in an external system and do not have specific pipeline jobs.
- Require manual approval in another system.
@ -121,19 +121,19 @@
stage: Manage
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.html
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.html
image_url: https://about.gitlab.com/images/14_1/status-checks-pending.png
published_at: 2021-07-22
release: 14.1
- title: Pronouns viewable in user profile snapshot
body: |
- name: Pronouns viewable in user profile snapshot
description: |
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
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/profile/#add-your-gender-pronouns'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/profile/#add-your-gender-pronouns'
image_url: https://about.gitlab.com/images/14_1/pronouns.png
published_at: 2021-07-22
release: 14.1

56
data/whats_new/202108190001_14_02.yml
View File

@ -1,85 +1,85 @@
- title: Add pronunciation to GitLab profile page
body: |
- name: Add pronunciation to GitLab profile page
description: |
You can now add pronunciation to your user profile. In distributed teams where team members are from different countries, it can be difficult to determine how to say someone's name correctly. This will help others know how to pronounce your name.
stage: Manage
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/profile/#add-your-pronunciation'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/profile/#add-your-pronunciation'
image_url: https://about.gitlab.com/images/14_2/pronounce.png
published_at: 2021-08-22
release: 14.2
- title: View historical CI pipeline minute usage
body: |
- name: View historical CI pipeline minute usage
description: |
Before GitLab 14.2, the CI pipeline minutes usage on the [Usage Quotas](https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#shared-runners-pipeline-minutes-quota) page only showed the current month's usage. This data would reset every month and there was no way to view activity from the past months for analyzing historical usage.
Now there are two charts that show historical CI pipeline minutes usage by month or by project, so you can make informed decisions about your pipeline usage.
stage: Verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/subscriptions/gitlab_com/index.html#ci-pipeline-minutes'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/subscriptions/gitlab_com/index.html#ci-pipeline-minutes'
image_url: https://about.gitlab.com/images/14_2/CI_minutes_usage_graph.png
published_at: 2021-08-22
release: 14.2
- title: Edit issue title from an issue board
body: |
- name: Edit issue title from an issue board
description: |
Editing an issue in an issue board currently requires many steps and takes you out of your workflow. We've added an easy way to edit an issue's title right in the issue board, without navigating to another page. To edit the title, in the right sidebar, select the issue, then select **Edit**.
stage: Plan
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/project/issue_board.html#edit-an-issue'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/project/issue_board.html#edit-an-issue'
image_url: https://about.gitlab.com/images/14_2/issue-board-edit-title.gif
published_at: 2021-08-22
release: 14.2
- title: Preview Markdown live while editing
body: |
- name: Preview Markdown live while editing
description: |
Markdown is a fast and intuitive syntax for writing rich web content. Until it isn't. Luckily, it's easy to preview the rendered output of Markdown to ensure the accuracy of your markup from the **Preview** tab. Unfortunately, the context switch required to move between the raw source code and the preview can be tedious and disruptive to your flow.
Now, in both the Web IDE and single file editor, Markdown files have a new live preview option available. Right-click the editor and select **Preview Markdown** or use `Command/Control + Shift + P` to toggle a split-screen live preview of your Markdown content. The preview refreshes as you type, so you can be confident that your markup is valid and will render as you intended.
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/project/web_ide/#markdown-editing'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/project/web_ide/#markdown-editing'
image_url: https://about.gitlab.com/images/14_2/create-markdown-live-preview.png
published_at: 2021-08-22
release: 14.2
- title: Stageless pipelines
body: |
- name: Stageless pipelines
description: |
Using the [`needs`](https://docs.gitlab.com/ee/ci/yaml/#needs) keyword in your pipeline configuration helps to reduce cycle times by ignoring stage ordering and running jobs without waiting for others to complete. Previously, `needs` could only be used between jobs on different stages.
In this release, we've removed this limitation so you can define a `needs` relationship between any job you want. As a result, you can now create a complete CI/CD pipeline without using stages by including `needs` in every job to implicitly configure the execution order. This lets you define a less verbose pipeline that takes less time to create and can run even faster.
stage: Verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/ci/yaml/#needs'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/#needs'
image_url: https://about.gitlab.com/images/14_2/need.png
published_at: 2021-08-22
release: 14.2
- title: New GitLab Kubernetes Agent UI
body: |
- name: New GitLab Kubernetes Agent UI
description: |
The GitLab Kubernetes Agent allows a secure bi-directional connection between GitLab and any Kubernetes cluster. Until now, registering a new Kubernetes Agent required writing GraphQL queries.
As of GitLab 14.2, GitLab ships with a user-friendly user interface and a registration form to help you get started with the Kubernetes Agent with ease.
stage: Configure
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/clusters/agent/'
available_in: [Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/clusters/agent/'
image_url: https://about.gitlab.com/images/14_2/k8s-agent-registration.png
published_at: 2021-08-22
release: 14.2
- title: Create a GitLab branch from a Jira issue
body: |
- name: Create a GitLab branch from a Jira issue
description: |
Users of the [GitLab.com for Jira Cloud](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud) application can now create GitLab branches directly from a Jira issue's [development panel](https://support.atlassian.com/jira-software-cloud/docs/view-development-information-for-an-issue/). This enables developers to begin work on issues without having to switch tools and lose context.
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/integration/jira/connect-app.html'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/integration/jira/connect-app.html'
image_url: https://about.gitlab.com/images/14_2/jira_dev_panel_jira_setup_3.png
published_at: 2021-08-22
release: 14.2

56
data/whats_new/202109200001_14_03.yml
View File

@ -1,83 +1,83 @@
- title: Project-level DAST and secret detection scan execution policies
body: |
- name: Project-level DAST and secret detection scan execution policies
description: |
We have completed the first iterative step [toward our vision](https://about.gitlab.com/direction/protect/security_orchestration/) of bringing unified security policies to GitLab. Users can now require DAST and secret detection scans to run on a regular schedule or as part of project CI pipelines, independent of the `.gitlab-ci.yml` file's contents. This allows security teams to separately manage these scan requirements without allowing developers to change the configuration. You can get started with these policies on the **Security & Compliance > Policies** page.
stage: Protect
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: 'https://docs.gitlab.com/ee/user/application_security/policies/'
available_in: [Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/application_security/policies/'
image_url: https://about.gitlab.com/images/14_3/security_policies.png
published_at: 2021-09-22
release: 14.3
- title: Next Generation SAST to reduce Ruby false positives
body: |
- name: Next Generation SAST to reduce Ruby false positives
description: |
GitLab SAST historically has been powered by [over a dozen open-source static analysis security analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks). These analyzers have proactively identified millions of vulnerabilities for developers using GitLab every month. These tools use a variety of different approaches for identifying vulnerabilities from basic regex pattern matching to abstract syntax tree parsing which can lead to issues with false positives. GitLab's Secure tools already offer vulnerability fingerprinting allowing you to dismiss these false positives persistently, however, we want to go a step further and not require this manual triaging.
Today we're releasing the first version of our proprietary static application security testing engine built in-house and maintained by GitLab's Static Analysis and Vulnerability Research groups. Initially, this tool is focused on Ruby and Rails to help reduce false positives.
stage: Secure
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: 'https://docs.gitlab.com/ee/user/application_security/sast/#false-positive-detection'
available_in: [Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/application_security/sast/#false-positive-detection'
image_url: https://about.gitlab.com/images/14_3/secure-fp-reduction-ui.png
published_at: 2021-09-22
release: 14.3
- title: Group-level permissions for Protected Environments
body: |
- name: Group-level permissions for Protected Environments
description: |
In this release, we are introducing group-level protected environments, based on the [deployment tier](https://docs.gitlab.com/ee/ci/environments/index.html#deployment-tier-of-environments) as the identifier. This enables operators to responsibly lock down deployments to higher tier environments without unnecessarily preventing developers from doing their work as the maintainers of their individual projects.
stage: Release
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/ci/environments/protected_environments.html#group-level-protected-environments'
available_in: [Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/ci/environments/protected_environments.html#group-level-protected-environments'
image_url: https://about.gitlab.com/images/growth/release.png
published_at: 2021-09-22
release: 14.3
- title: Edit a table's structure visually in the new wiki editor
body: |
- name: Edit a table's structure visually in the new wiki editor
description: |
Editing a Markdown table that has 9 columns and 25 rows is one thing. But adding a tenth column to that table in Markdown? That involves very repetitive and error-prone edits to every row. One mistake or misplaced `|` and the table fails to render.
The new WYSIWYG Markdown editor in the wiki lets you quickly and easily insert a table using the button in the toolbar. After selecting the initial number of rows and columns, however, dealing with the structure of the table can be more difficult. In GitLab 14.3, you can now click on the caret icon in the top right corner of any selected cell to add or remove columns and rows, either before or after the selected cell. Now, as your content scales, the complexity doesn't follow suit.
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/project/wiki/#content-editor'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/project/wiki/#content-editor'
image_url: https://about.gitlab.com/images/14_3/wiki-editor-edit-table-structure.png
published_at: 2021-09-22
release: 14.3
- title: Use variables in other variables
body: |
- name: Use variables in other variables
description: |
CI/CD pipeline execution scenarios can depend on expanding variables declared in a pipeline or using GitLab predefined variables within another variable declaration. In 14.3, we are enabling the "variables inside other variables" feature on GitLab SaaS. Now you can define a variable and use it in another variable definition within the same pipeline. You can also use GitLab predefined variables inside of another variable declaration. This feature simplifies your pipeline definition and eliminates pipeline management issues caused by the duplicating of variable data. Note - for GitLab self-managed customers the feature is disabled by default. To use this feature, your GitLab administrator will need to enable the [feature flag](https://docs.gitlab.com/ee/ci/variables/where_variables_can_be_used.html#nested-variable-expansion).
stage: Verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/ci/variables/#use-variables-in-other-variables'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/ci/variables/#use-variables-in-other-variables'
image_url: https://about.gitlab.com/images/growth/verify.png
published_at: 2021-09-22
release: 14.3
- title: Add GitLab CI/CD configuration conditionally with `include`
body: |
- name: Add GitLab CI/CD configuration conditionally with `include`
description: |
[`include`](https://docs.gitlab.com/ee/ci/yaml/index.html#include) is one of the most popular keywords to use when writing a full CI/CD pipeline. If you are building larger pipelines, you are probably using the `include` keyword to bring external YAML configuration into your pipeline.
In this release, we are expanding the power of the keyword so you can use `include` with [`rules`](https://docs.gitlab.com/ee/ci/yaml/index.html#include) conditions. Now, you can decide when external CI/CD configuration should or shouldn't be included. This will help you write a standardized pipeline with the ability to dynamically modify itself based on the conditions you choose.
stage: Verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/#amazing'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/#amazing'
image_url: https://about.gitlab.com/images/14_3/conditional_include.png
published_at: 2021-09-22
release: 14.3
- title: Grant group access to the GitLab Kubernetes Agent
body: |
- name: Grant group access to the GitLab Kubernetes Agent
description: |
The GitLab Kubernetes Agent provides a secure connection between a Kubernetes cluster and GitLab. Until GitLab 14.2, the GitLab CI/CD enabled pushing to a cluster only from the same project where the Kubernetes Agent was registered. In GitLab 14.3, the Agent can be authorized to access entire groups. As a result, every project under the authorized group has access to the cluster without the need to register an agent for every project.
stage: Configure
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/clusters/agent/repository.html#authorize-groups-to-use-an-agent'
available_in: [Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/clusters/agent/repository.html#authorize-groups-to-use-an-agent'
image_url: https://about.gitlab.com/images/growth/configure.png
published_at: 2021-09-22
release: 14.3

40
data/whats_new/2021102000001_14_04.yml
View File

@ -1,16 +1,16 @@
- title: Scheduled DAST scans
body: |
- name: Scheduled DAST scans
description: |
GitLab’s Dynamic Application Security Testing (DAST) now supports scheduled on-demand scans. Previously, on-demand DAST scans could only be manually triggered, which limited the usability to scans that you wanted to run immediately. With this new scheduler, you can set a DAST scan to run either once at a specific time in the future, or on a recurring basis. If adding DAST to your pipelines is not an option for your organization, or if the security or compliance regulations for your area require a scan to be scheduled, this feature provides an easy way to create a scheduled scan to meet your needs. The scan can be associated with the default branch, which allows for the results to show on the Secure Dashboard and Vulnerability list. Combined with the scan and site profiles, the scheduled on-demand scans give you quick and easy access to DAST results for your application or API, on a schedule that works for your development and security teams.
stage: Secure
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: 'https://docs.gitlab.com/ee/user/application_security/dast/index.html#schedule-an-on-demand-scan'
available_in: [Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/application_security/dast/index.html#schedule-an-on-demand-scan'
image_url: https://about.gitlab.com/images/14_4/dast_on_demand_schedule.png
published_at: 2021-10-22
release: 14.4
- title: Remote Repositories for GitLab in Visual Studio Code
body: |
- name: Remote Repositories for GitLab in Visual Studio Code
description: |
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.
@ -19,41 +19,41 @@
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md#browse-a-repository-without-cloning'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md#browse-a-repository-without-cloning'
image_url: https://img.youtube.com/vi/p4GTVx_Nd2s/hqdefault.jpg
published_at: 2021-10-22
release: 14.4
- title: The GitLab Operator is Generally Available
body: |
- name: The GitLab Operator is Generally Available
description: |
GitLab 14.4 is proud to announce the general availability of [the GitLab Operator](https://about.gitlab.com/blog/2021/10/12/open-shift-ga/), with the ability to run production instances of GitLab on Kubernetes platforms, including Red Hat OpenShift. The GitLab Operator also automates day 2 operations such as upgrading components, application reconfiguration, and autoscaling. Check out the [GitLab Operator installation documentation](https://docs.gitlab.com/charts/installation/operator.html) for additional information.
stage: Enablement
self-managed: true
gitlab-com: false
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/charts/installation/operator.html'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/charts/installation/operator.html'
image_url: https://img.youtube.com/vi/sEBnuhzYD2I/hqdefault.jpg
published_at: 2021-10-22
release: 14.4
- title: DevOps Adoption trend graph
body: |
- name: DevOps Adoption trend graph
description: |
In GitLab 14.4, we added a new graph to group-level DevOps Adoption for trend over time. This graph shows you how groups adopt DevOps features over time and can give insights into how quickly groups are adopting additional DevOps processes. This is broken down by Dev, Sec, and Ops functionality.
stage: Manage
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: 'https://docs.gitlab.com/ee/user/group/devops_adoption/#adoption-over-time'
available_in: [Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/group/devops_adoption/#adoption-over-time'
image_url: https://about.gitlab.com/images/14_4/devops_adop_table.png
published_at: 2021-10-22
release: 14.4
- title: Integrated error tracking inside GitLab without a Sentry instance
body: |
- name: Integrated error tracking inside GitLab without a Sentry instance
description: |
Prior to GitLab 14.4, you could integrate with Sentry Error Tracking by supplying an endpoint for a Sentry backend (either self-deployed or in their cloud service). With GitLab 14.4, you now have access to a Sentry-compatible backend built into your GitLab instance. This allows you to quickly instrument your apps so your errors show up directly in GitLab without the need for a separate Sentry instance.
stage: Manage
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/operations/error_tracking.html#integrated-error-tracking'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/operations/error_tracking.html#integrated-error-tracking'
image_url: https://about.gitlab.com/images/14_4/monitor-integrated-error-tracking.png
published_at: 2021-10-22
release: 14.4

48
data/whats_new/2021111800001_14_05.yml
View File

@ -1,27 +1,27 @@
- title: Introducing Infrastructure as Code (IaC) security scanning
body: |
- name: Introducing Infrastructure as Code (IaC) security scanning
description: |
With GitLab 14.5 we're introducing security scanning for Infrastructure as Code (IaC) configuration files. Like all our SAST scanners, we've chosen to make this capability available for all customers for free to encourage secure coding practices with the rise of IaC. The initial version of this IaC security scanner supports configuration files for Terraform, Ansible, AWS CloudFormation, and Kubernetes and is based on the open-source [Keeping Infrastructure as Code Secure (KICS) project](https://kics.io/). This new IaC scanning capability joins our [existing Kubernetes manifest SAST scanner](https://docs.gitlab.com/ee/user/application_security/sast/#enabling-kubesec-analyzer).
stage: Secure
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/application_security/iac_scanning/'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/application_security/iac_scanning/'
image_url: https://about.gitlab.com/images/14_5/gitlab-iac.png
published_at: 2021-11-22
release: 14.5
- title: Add personal README to profile
body: |
- name: Add personal README to profile
description: |
You can now add a README section to your GitLab profile! This is a great way to tell others about, your interests, how you work, or anything else you want! To add a README section, create a new public project with the same name as your user account and add a new [README file](https://docs.gitlab.com/ee/user/project/repository/index.html#readme-and-index-files). The contents of that file are automatically shown on your GitLab profile.
stage: Manage
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/profile/#add-details-to-your-profile-with-a-readme'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/profile/#add-details-to-your-profile-with-a-readme'
image_url: https://about.gitlab.com/images/14_5/user_profiles_readme.png
published_at: 2021-11-22
release: 14.5
- title: Geo provides a single command to promote a secondary node
body: |
- name: Geo provides a single command to promote a secondary node
description: |
When performing a failover, systems administrators use different tools depending on the underlying architecture. On a single-node Geo site, administrators can use the `gitlab-ctl promote-to-primary-node` command. However, multi-node sites did not support this command and required manual editing of configuration. This was cumbersome for large environments because it required updating dozens of configuration files.
Now, administrators can use `gitlab-ctl geo promote` on any node of a Geo secondary site to promote it to a primary. In a disaster recovery scenario or planned failover, this saves precious time and reduces potential errors when promoting a secondary site to a primary. This command also makes it easier to script the failover process.
@ -30,13 +30,13 @@
stage: Enablement
self-managed: true
gitlab-com: false
packages: [Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/administration/geo/disaster_recovery/planned_failover.html'
available_in: [Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/administration/geo/disaster_recovery/planned_failover.html'
image_url: https://about.gitlab.com/images/growth/enablement.png
published_at: 2021-11-22
release: 14.5
- title: Group-level settings for merge request approvals
body: |
- name: Group-level settings for merge request approvals
description: |
You can now define and enforce values for merge request approval settings at the group level. These values cascade and are used by any projects within the group. Group-level merge request approvals make it easy for organizations to ensure proper separation of duties across all teams. You only have to specify settings in a single location now, rather than needing to update and monitor every project.
When these settings are set at the group level, you:
@ -46,32 +46,32 @@
stage: Manage
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/group/#group-approval-rules'
available_in: [Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/group/#group-approval-rules'
image_url: https://about.gitlab.com/images/14_5/group_level_mr_settings_picture.png
published_at: 2021-11-22
release: 14.5
- title: GitLab Kubernetes Agent available in GitLab Free
body: |
- name: GitLab Kubernetes Agent available in GitLab Free
description: |
Connecting a Kubernetes cluster with the GitLab Kubernetes Agent simplifies the setup for cluster applications and enables secure GitOps deployments to the cluster. Initially, the GitLab Kubernetes Agent was available only for Premium users. In our commitment to the open source ethos, we moved the core features of the GitLab agent for Kubernetes and the ability to use CI/CD with Kubernetes to GitLab Free. We expect that the open-sourced features are compelling to many users without dedicated infrastructure teams and strong requirements around cluster management. Advanced features remain available as part of the GitLab Premium offering.
stage: Configure
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/clusters/agent/'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/clusters/agent/'
image_url: https://about.gitlab.com/images/growth/configure.png
published_at: 2021-11-22
release: 14.5
- title: Cleaner diffs for Jupyter Notebook files
body: |
- name: Cleaner diffs for Jupyter Notebook files
description: |
Jupyter notebooks are key to data scientists' and machine learning engineers' workflows, but the file structure makes code review challenging. Often, the files can't be reviewed properly, and users are forced to accept those changes or treat their repositories as stores of data versus collaborative projects.
Now GitLab automatically strips out the noise and displays a cleaner version of the diff for these files. Human-readable diffs make it easier to review the substance of the change, without worrying about the formatting pieces that Jupyter Notebooks need.
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/project/repository/jupyter_notebooks/#cleaner-diffs'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/project/repository/jupyter_notebooks/#cleaner-diffs'
image_url: https://about.gitlab.com/images/14_5/create-code-review-jupyter-notebook-diffs.png
published_at: 2021-11-22
release: 14.5

40
data/whats_new/202112200001_14_06.yml
View File

@ -1,57 +1,57 @@
- title: Seamless worldwide performance with Geo
body: |
- name: Seamless worldwide performance with Geo
description: |
In GitLab 14.6, Geo secondary sites transparently proxy write requests to the primary site while accelerating most read requests. Systems administrators can provide all GitLab users across their organization with a single URL that automatically uses the Geo site closest to them. Users no longer need to use different configuration to benefit from Geo, or worry about what operations won’t work on Geo secondary sites. Globally distributed teams now benefit from accelerated git clone or git pull commands, and a seamless worldwide experience.
stage: Enablement
self-managed: true
gitlab-com: false
packages: [Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/administration/geo/secondary_proxy/'
available_in: [Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/administration/geo/secondary_proxy/'
image_url: https://about.gitlab.com/images/14_6/geo_secondary_proxy_flow.png
published_at: 2021-12-22
release: 14.6
- title: GitLab Agent's activity information
body: |
- name: GitLab Agent's activity information
description: |
Being able to monitor your cluster's activity helps you detect and troubleshoot faulty events, and rest assured when they succeed. GitLab now ships with an activity list for the GitLab Agent that logs real-time events. This first implementation logs connection and token statuses and will be followed with more events in future releases.
stage: Configure
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/clusters/agent/install/#view-agent-activity-information'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/clusters/agent/install/#view-agent-activity-information'
image_url: https://about.gitlab.com/images/14_6/gitlab_agent_activity_events_v14_6.png
published_at: 2021-12-22
release: 14.6
- title: SAST Support for .NET 6
body: |
- name: SAST Support for .NET 6
description: |
We have updated our .NET SAST analyzer, [Security Code Scan](https://security-code-scan.github.io/), to support this new version, which is also now supported with [our SAST language detection](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks), allowing GitLab SAST to automatically detect .NET 6 projects. This change was part of a community contribution by [@vasyl11](https://gitlab.com/vasyl11) at [Clay Solutions](https://my-clay.com/), who we thank for their efforts.
stage: Secure
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/application_security/sast/analyzers'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/application_security/sast/analyzers'
image_url: https://about.gitlab.com/images/14_6/14_6-cover-image.jpg
published_at: 2021-12-22
release: 14.6
- title: Toggle wiki editors seamlessly
body: |
- name: Toggle wiki editors seamlessly
description: |
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.
stage: Create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/project/wiki/#content-editor'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/project/wiki/#content-editor'
image_url: https://docs.gitlab.com/ee/user/project/wiki/img/content_editor_v14.6.png
published_at: 2021-12-22
release: 14.6
- title: Custom ruleset composability for SAST and Secret Detection
body: |
- name: Custom ruleset composability for SAST and Secret Detection
description: |
Custom Rulesets let users tailor the behavior of SAST and Secret Detection analyzers to their organization’s preferences. We're introducing the ability to add rules from multiple sources, like Git repositories, local files, and raw source changes. This change makes it easier to synthesize and manage multiple custom rulesets from different locations, which organizations can use to inherit rules across repositories and sources for greater flexibility. Initially, this change is available for our [SAST Semgrep, Nodejs, and Gosec analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#customize-rulesets) and [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/#custom-rulesets). We will expand this capability to our other analyzers [in future releases](https://gitlab.com/groups/gitlab-org/-/epics/4179).
stage: Secure
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: 'https://docs.gitlab.com/ee/user/application_security/sast/#customize-rulesets'
available_in: [Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/application_security/sast/#customize-rulesets'
image_url: https://docs.gitlab.com/ee/user/application_security/img/mr_security_scanning_results_v14_3.png
published_at: 2021-12-22
release: 14.6

24
data/whats_new/202201200001_14_07.yml
View File

@ -1,16 +1,16 @@
- title: GitLab Runner compliant with FIPS 140-2
body: |
- name: GitLab Runner compliant with FIPS 140-2
description: |
For some GitLab customers, U.S. government regulatory requirements require the use of FIPS (Federal Information Processing Standards) compliant software. The FIPS 140-2 and FIPS 140-3 publications define the security requirements for cryptographic modules used in computer and telecommunication systems, and within cyber systems that protect sensitive information. GitLab Runner is now FIPS 140-2 compliant for AMD64 compute architectures and Red Hat Enterprise Linux (RHEL) distributions. Refer to [this epic](https://gitlab.com/groups/gitlab-org/-/epics/5104) to follow the discussions about making GitLab FIPS compliant.
stage: Verify
self-managed: true
gitlab-com: false
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/runner/install/index.html#fips-compliant-gitlab-runner'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/runner/install/index.html#fips-compliant-gitlab-runner'
image_url: https://about.gitlab.com/images/growth/verify.png
published_at: 2022-01-22
release: 14.7
- title: Streaming audit events
body: |
- name: Streaming audit events
description: |
You can now stream audit events to a destination of your choosing! This is a great way to correlate GitLab audit events with other data streams you have, maintain a backup of audit events, or build out your own automation to take action when a specific audit event happens.
You can specify an HTTPS endpoint with our new GraphQL API and events are sent to it as webhooks. These messages contain the same information as the Audit Events UI about what type of change happened, when it happened, who was involved, as well as some additional metadata.
@ -19,13 +19,13 @@
stage: Manage
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: 'https://docs.gitlab.com/ee/administration/audit_event_streaming.html'
available_in: [Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/administration/audit_event_streaming.html'
image_url: https://about.gitlab.com/images/growth/manage.jpg
published_at: 2022-01-22
release: 14.7
- title: Group access tokens
body: |
- name: Group access tokens
description: |
With group access tokens, you can use a single token to perform actions for groups, manage the projects within the group, and, in GitLab 14.2 and later, authenticate with Git over HTTPS.
Previously, group access tokens were limited to self-managed instances only, and could only be generated using the Rails console. Now, you can create group access tokens using the UI and API. You can define token name, expiration date, and scope. You can also revoke an existing group access token.
@ -34,8 +34,8 @@
stage: Manage
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html'
image_url: https://about.gitlab.com/images/14_7/group_access_token.png
published_at: 2022-01-22
release: 14.7

48
data/whats_new/202202210001_14_08.yml
View File

@ -1,5 +1,5 @@
- title: "Support for ecdsa-sk and ed25519-sk SSH keys"
body: |
- name: "Support for ecdsa-sk and ed25519-sk SSH keys"
description: |
[OpenSSH 8.2](https://www.openssh.com/releasenotes.html#8.2) added support for FIDO/U2F hardware authenticators with new
ecdsa-sk and ed25519-sk key types.
@ -7,24 +7,24 @@
stage: manage
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/ssh/#generate-an-ssh-key-pair-for-a-fidou2f-hardware-security-key'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/ssh/#generate-an-ssh-key-pair-for-a-fidou2f-hardware-security-key'
image_url: 'https://about.gitlab.com/images/14_8/ssh_key.png'
published_at: 2022-02-22
release: 14.8
- title: "Auto-completion of keywords in the Pipeline Editor"
body: |
- name: "Auto-completion of keywords in the Pipeline Editor"
description: |
Writing a valid GitLab CI/CD pipeline can be difficult regardless of whether you're a novice or more advanced user. Syntax structure should be accurate and even a small typo or misconfiguration could cause your pipeline to be invalid, introducing more work to find the source of the problem. In this release, we've added auto-completion of CI/CD keywords to the pipeline editor, which will greatly increase your efficiency when writing and debugging pipelines. You'll be more confident that your pipeline will run the way you want it the very first time it runs.
stage: verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/ci/pipeline_editor/index.html#validate-ci-configuration'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/ci/pipeline_editor/index.html#validate-ci-configuration'
image_url: 'https://about.gitlab.com/images/growth/verify.png'
published_at: 2022-02-22
release: 14.8
- title: "Security approval policies"
body: |
- name: "Security approval policies"
description: |
GitLab now supports flexible security approvals as the replacement for the deprecated Vulnerability-Check feature. Security approvals are similar to Vulnerability-Check in that both can require approvals for MRs that contain security vulnerabilities. However, security approvals improve the previous experience in several ways:
- Users can choose who is allowed to edit security approval rules. An independent security or compliance team can therefore manage rules in a way that prevents development project maintainers from modifying the rules.
@ -36,24 +36,24 @@
stage: protect
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: 'https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies'
available_in: [Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies'
image_url: 'https://about.gitlab.com/images/14_8/protect-security-approval-policies.png'
published_at: 2022-02-22
release: 14.8
- title: "On-demand security scan index view"
body: |
- name: "On-demand security scan index view"
description: |
Find all your on-demand DAST and DAST API scans on a single page. We have introduced a new index page for on-demand scans that shows your in-progress scans, previously run scans, saved scans, and scheduled scans. From this index page, you can find specific scans easily or re-run scans that have already finished. In previous versions of GitLab, to see on-demand scans that were in-progress or had finished, you needed to search through the pipelines page to find the right pipeline. Saved on-demand scans were located in the Security & Compliance configuration section. To find scheduled scans, you needed to look at each saved scan individually to see their schedule. All of those activities are now rolled into one page to make it easier to run on-demand security testing outside of CI/CD builds, MRs, or pipelines.
stage: secure
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: 'https://docs.gitlab.com/ee/user/application_security/dast/#view-on-demand-dast-scans'
available_in: [Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/application_security/dast/#view-on-demand-dast-scans'
image_url: 'https://about.gitlab.com/images/14_8/dast-on-demand-index-page.png'
published_at: 2022-02-22
release: 14.8
- title: "User impersonation audit events for groups"
body: |
- name: "User impersonation audit events for groups"
description: |
GitLab now provides audit events on the group audit events page for
[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
@ -71,21 +71,21 @@
stage: manage
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/administration/audit_events.html#group-events'
available_in: [Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/administration/audit_events.html#group-events'
image_url: 'https://about.gitlab.com/images/14_8/impersonation_audit_event.png'
published_at: 2022-02-22
release: 14.8
- title: "Additional display options for roadmaps"
body: |
- name: "Additional display options for roadmaps"
description: |
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.
stage: plan
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/user/group/roadmap/index.html#roadmap-settings'
available_in: [Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/group/roadmap/index.html#roadmap-settings'
image_url: 'https://about.gitlab.com/images/14_8/rp_roadmap_settings.png'
published_at: 2022-02-22
release: 14.8

48
data/whats_new/202203210001_14_09.yml
View File

@ -1,62 +1,62 @@
- title: "Link an epic to another epic"
body: |
- name: "Link an epic to another epic"
description: |
GitLab now supports linking epics using "related", "blocking," or "blocked" relationships. This feature enables teams to better track and manage epic dependencies across GitLab groups. Effective dependency management is a key component of reducing variability and increasing predictability in value delivery.
stage: plan
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: 'https://docs.gitlab.com/ee/user/group/epics/linked_epics.html'
available_in: [Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/group/epics/linked_epics.html'
image_url: 'https://about.gitlab.com/images/14_9/related_epics_add.png'
published_at: 2022-03-22
release: 14.9
- title: "Rule mode for scan result policies"
body: |
- name: "Rule mode for scan result policies"
description: |
With the GitLab 14.9 release, users can now use rule mode to design and edit scan result policies without needing to edit the policy's YAML directly. This new UI editor makes it easier for users who want to create and manage MR approval rules that are triggered when a given threshold of vulnerabilities are detected in the MR.
To get started with this new rule mode, navigate to **Security & Compliance > Policies** and create a new Scan Result policy.
stage: protect
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: 'https://docs.gitlab.com/ee/user/application_security/policies/#policy-editor'
available_in: [Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/application_security/policies/#policy-editor'
image_url: 'https://about.gitlab.com/images/14_9/protect-scan-result-policy-rule-mode.png'
published_at: 2022-03-22
release: 14.9
- title: "Deployment Approval on the Environments page"
body: |
- name: "Deployment Approval on the Environments page"
description: |
We are excited to introduce the Deployment Approval capability in the GitLab interface. In GitLab 14.8, we introduced the ability to approve deployments via the [API](https://docs.gitlab.com/ee/ci/environments/deployment_approvals.html#using-the-api). Now, deployment approvers can view a pending deployment and approve or reject it conveniently directly in the Environments page. This update continues our work to enable teams to create workflows for approving software to go to production or other protected environments. With this update, we are now upgrading the feature to beta.
stage: "Release"
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/ci/environments/deployment_approvals.html#approve-or-reject-a-deployment'
available_in: [Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/ci/environments/deployment_approvals.html#approve-or-reject-a-deployment'
image_url: 'https://about.gitlab.com/images/growth/release.png'
published_at: 2022-03-22
release: 14.9
- title: "New design for the Environments Page"
body: |
- name: "New design for the Environments Page"
description: |
Previously, the Environments page enabled you to operate and understand deployments but the design hid some important information and was difficult to read. In GitLab 14.9, we made a comprehensive update to the page so that you can answer key questions about your environments and deployments. Now, you can easily see the status of the latest deployment, the status for various environments, and which commits have been deployed.
stage: "Release"
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/ci/environments/#view-environments-and-deployments'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/ci/environments/#view-environments-and-deployments'
image_url: 'https://about.gitlab.com/images/14_9/release-enviroments-page-redesign.png'
published_at: 2022-03-22
release: 14.9
- title: "Project Level Time to restore service API"
body: |
- name: "Project Level Time to restore service API"
description: |
In this release, we added API support for Time to Restore Service. This is the 3rd of the 4 [DORA Metrics](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#devops-research-and-assessment-dora-key-metrics). This data helps teams continuously improve in their stability metrics.
stage: manage
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: 'https://docs.gitlab.com/ee/api/dora/metrics.html'
available_in: [Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/api/dora/metrics.html'
image_url: 'https://about.gitlab.com/images/14_9/ttr_api.png'
published_at: 2022-03-22
release: 14.9
- title: "Integrated security training"
body: |
- name: "Integrated security training"
description: |
GitLab provides a comprehensive set of [security scanning tools](https://docs.gitlab.com/ee/user/application_security/#security-scanning-tools)
that can identify all manner of security issues. Scanner findings are presented
in merge requests, pipelines, and in a dedicated Vulnerability Report. When
@ -78,8 +78,8 @@
stage: secure
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: 'https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#enable-security-training-for-vulnerabilities'
available_in: [Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#enable-security-training-for-vulnerabilities'
image_url: 'https://about.gitlab.com/images/14_9/secure-enable-security-training.png'
published_at: 2022-03-22
release: 14.9

32
data/whats_new/202204210001_14_10.yml
View File

@ -1,48 +1,48 @@
- title: "Compliance report individual violation reporting"
body: |
- name: "Compliance report individual violation reporting"
description: |
The compliance report now reports every individual merge request violation for the projects within a group. This is a huge improvement over the previous version, which only showed the latest MR that had one or more violations. The new version allows you to see history and patterns of violations over time.
stage: manage
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: 'https://docs.gitlab.com/ee/user/compliance/compliance_report/'
available_in: [Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/user/compliance/compliance_report/'
image_url: 'https://about.gitlab.com/images/14_10/manage_compliance_report_individual_violation.png'
published_at: 2022-04-22
release: 14.10
- title: "Improved pipeline variables inheritance"
body: |
- name: "Improved pipeline variables inheritance"
description: |
Previously, it was possible to pass some CI/CD variables to a downstream pipeline through a trigger job, but variables added in manual pipeline runs or by using the API could not be forwarded.
In this release we've added a new `trigger:forward` keyword to control what things you forward to downstream parent-child pipelines or multi-project pipelines, which provides a flexible way to handle variable inheritance in downstream pipelines.
stage: verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/ci/yaml/#triggerforward'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/#triggerforward'
image_url: 'https://about.gitlab.com/images/growth/verify.png'
published_at: 2022-04-22
release: 14.10
- title: "Escalating manually created incidents"
body: |
- name: "Escalating manually created incidents"
description: |
Incident Management is set up to trigger escalation policies for new alerts. In this scenario, the on-call responder who is paged can end the paging by acknowledging the alert. If the responder changes the status back to triggered, we restart the escalation policy and begin paging again. When a user creates an incident manually, there is no associated alert and therefore no way to page on-call responders.
This release enables paging on manually created incidents. Responders now have the ability to acknowledge the page on incidents, or restart paging by resetting the status to triggered, just as you can for alerts.
stage: monitor
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/operations/incident_management/paging.html#escalating-an-incident'
available_in: [Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/operations/incident_management/paging.html#escalating-an-incident'
image_url: 'https://about.gitlab.com/images/14_10/manually_escalated_incident.png'
published_at: 2022-04-22
release: 14.10
- title: "Expanded view of group runners"
body: |
- name: "Expanded view of group runners"
description: |
Group runners are now displayed in an expanded view, where you can more easily administer and manage the runners associated with the namespace. To view the new UI, on the left sidebar, select **CI/CD**. This view includes the number of online, offline, and stale runners associated with the group and subgroups.
stage: verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: 'https://docs.gitlab.com/ee/ci/runners/runners_scope.html#group-runners'
available_in: [Free, Premium, Ultimate]
documentation_link: 'https://docs.gitlab.com/ee/ci/runners/runners_scope.html#group-runners'
image_url: 'https://about.gitlab.com/images/14_10/group-runners-view-new-3.png'
published_at: 2022-04-22
release: 14.10

64
data/whats_new/202205220001_15_0.yml
View File

@ -1,5 +1,5 @@
- title: Edit code blocks, links, and media inline in the WYSIWYG editor # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: Edit code blocks, links, and media inline in the WYSIWYG editor # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
GitLab 15.0 includes a few exciting improvements to speed up your workflow in the WYSIWYG Markdown editor for your wikis.
First, you'll find no more un-styled, monochrome code blocks: choose from over 100 languages in the dropdown list above the code block so your `CSS`, `YAML`, and `Python` code are distinct from each other with accurate syntax highlighting. The code blocks will even inherit your preferred syntax highlighting theme. You can also quickly copy the code block to your clipboard for use in your code editor of choice.
@ -8,26 +8,26 @@
stage: create # String value of the stage that the feature was created in. e.g., Growth
self-managed: true # Boolean value (true or false)
gitlab-com: true # Boolean value (true or false)
packages: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/wiki/#content-editor # This is the documentation URL, but can be a URL to a video if there is one
available_in: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/wiki/#content-editor # This is the documentation URL, but can be a URL to a video if there is one
image_url: https://about.gitlab.com/images/15_0/inline-editing-in-wysiwyg.png # 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: 2022-05-22 # YYYY-MM-DD
release: 15.0 # XX.Y
- title: Advanced Search is compatible with OpenSearch # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: Advanced Search is compatible with OpenSearch # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
[OpenSearch](https://opensearch.org) is an open source Elasticsearch fork. Prior to GitLab 15.0, Advanced Search was not compatible with OpenSearch. If you used AWS-managed services, you had to use older versions of Elasticsearch.
You can now take full advantage of OpenSearch for Advanced Search.
stage: enablement # String value of the stage that the feature was created in. e.g., Growth
self-managed: true # Boolean value (true or false)
gitlab-com: true # Boolean value (true or false)
packages: [Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
url: https://docs.gitlab.com/ee/integration/elasticsearch.html # This is the documentation URL, but can be a URL to a video if there is one
available_in: [Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/integration/elasticsearch.html # This is the documentation URL, but can be a URL to a video if there is one
image_url: https://about.gitlab.com/images/15_0/gitlab_advanced_search_is_now_compatible_with_opensearch.png # 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: 2022-05-22 # YYYY-MM-DD
release: 15.0 # XX.Y
- title: Plan and schedule issues with automated iteration cadences # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: Plan and schedule issues with automated iteration cadences # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
In GitLab 14.10 and earlier, groups supported only one set of iterations. It made it difficult for different teams that worked in a single group to have autonomy with scheduling and tracking their issues from iteration to iteration. To improve this, we're adding the ability for a group to manage multiple sets of concurrent iterations with iteration cadences. This allows each team to have control over the start day and duration of each iteration in their iteration cadence.
The day-to-day management of iterations is now much more efficient too. When you create a new iteration cadence, select the first day of your first iteration, how many weeks each iteration should be, and how many upcoming iterations GitLab should maintain for you. You can also optionally enable unfinished issues to automatically roll over from one completed iteration to the next. After a cadence is created, GitLab automatically creates the specified number of upcoming iterations.
@ -36,13 +36,13 @@
stage: plan # String value of the stage that the feature was created in. e.g., Growth
self-managed: true # Boolean value (true or false)
gitlab-com: true # Boolean value (true or false)
packages: [Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/group/iterations/#iteration-cadences # This is the documentation URL, but can be a URL to a video if there is one
available_in: [Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/group/iterations/#iteration-cadences # This is the documentation URL, but can be a URL to a video if there is one
image_url: https://about.gitlab.com/images/15_0/iteration-cadences.png # 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: 2022-05-22 # YYYY-MM-DD
release: 15.0 # XX.Y
- title: Internal notes # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: Internal notes # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
In many cases, organizations want to keep issues and epics public, but apply stricter governance to conversations within them. For example, when using GitLab issues as part of Service Desk workflows, organizations may want to make core details about an issue public, but not to expose customer-specific confidential data broadly.
With internal notes, you can redact discussions with internal or customer data that should only be visible to certain users, while keeping the core details about an issue public. Internal notes in issues or epics can only be seen by the issue author, assignee, and group or project members with at least the Reporter role.
@ -51,13 +51,13 @@
stage: plan # String value of the stage that the feature was created in. e.g., Growth
self-managed: true # Boolean value (true or false)
gitlab-com: true # Boolean value (true or false)
packages: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/discussions/index.html#add-an-internal-note # This is the documentation URL, but can be a URL to a video if there is one
available_in: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/discussions/index.html#add-an-internal-note # This is the documentation URL, but can be a URL to a video if there is one
image_url: https://about.gitlab.com/images/15_0/add_internal_note_v15_0.png # 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: 2022-05-22 # YYYY-MM-DD
release: 15.0 # XX.Y
- title: Link external organizations and contacts to issues # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: Link external organizations and contacts to issues # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
GitLab 15.0 introduces the first [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc) toward [managing and billing external customers from GitLab](https://gitlab.com/groups/gitlab-org/-/epics/5323). With the customer relations management (CRM) feature, you can:
- Create organizations and contacts.
@ -72,43 +72,43 @@
stage: plan # String value of the stage that the feature was created in. e.g., Growth
self-managed: true # Boolean value (true or false)
gitlab-com: true # Boolean value (true or false)
packages: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/crm/ # This is the documentation URL, but can be a URL to a video if there is one
available_in: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/crm/ # This is the documentation URL, but can be a URL to a video if there is one
image_url: https://img.youtube.com/vi/8ubOS80yNvc/hqdefault.jpg # 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: 2022-05-22 # YYYY-MM-DD
release: 15.0 # XX.Y
- title: Container Scanning available in all tiers # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: Container Scanning available in all tiers # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
[Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/) helps developers to easily find known security vulnerabilities in dependencies that are installed in their container images. With GitLab 15.0, we are making the basic Container Scanning features available in every [GitLab tier](/pricing/).
stage: protect # String value of the stage that the feature was created in. e.g., Growth
self-managed: true # Boolean value (true or false)
gitlab-com: true # Boolean value (true or false)
packages: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/container_scanning/#capabilities # This is the documentation URL, but can be a URL to a video if there is one
available_in: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/container_scanning/#capabilities # This is the documentation URL, but can be a URL to a video if there is one
image_url: https://img.youtube.com/vi/vge_DQ6af9Y/hqdefault.jpg # 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: 2022-05-22 # YYYY-MM-DD
release: 15.0 # XX.Y
- title: Limited Availability GitLab SaaS runners on macOS (x86-64) # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: Limited Availability GitLab SaaS runners on macOS (x86-64) # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
GitLab SaaS runners on macOS are now in [Limited Availability](https://about.gitlab.com/handbook/product/gitlab-the-product/#limited-availability-la). If you use GitLab SaaS and have a Premium or Ultimate subscription, you can build applications that require macOS in a secure, on-demand GitLab Runner build environment that's fully integrated with GitLab CI/CD. As part of the Limited Availability release, CI jobs that run on the macOS runners will count toward your CI/CD minutes quota at a [cost factor](https://docs.gitlab.com/ee/ci/pipelines/cicd_minutes.html#cost-factor) of 6.
stage: verify # String value of the stage that the feature was created in. e.g., Growth
self-managed: false # Boolean value (true or false)
gitlab-com: true # Boolean value (true or false)
packages: [Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/runners/saas/macos_saas_runner.html # This is the documentation URL, but can be a URL to a video if there is one
available_in: [Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/runners/saas/macos_saas_runner.html # This is the documentation URL, but can be a URL to a video if there is one
image_url: https://img.youtube.com/vi/G7ektKx8slg/hqdefault.jpg # 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: 2022-05-22 # YYYY-MM-DD
release: 15.0 # XX.Y
- title: Use nested CI/CD variables with environments in pipeline configuration # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: Use nested CI/CD variables with environments in pipeline configuration # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
Using CI/CD variables with the `environments` keyword in your CI/CD configuration is great, because it lets you [create environments dynamically](https://docs.gitlab.com/ee/ci/environments/#create-a-dynamic-environment). While this is already a powerful feature, there were still some limitations, because you could not use nested variables to define environments.
Starting in GitLab 15.0, you can nest variables inside other variables, and have them all expand the way you expect. This makes dynamic environments even more powerful due to the increased flexibility!
stage: verify # String value of the stage that the feature was created in. e.g., Growth
self-managed: true # Boolean value (true or false)
gitlab-com: true # Boolean value (true or false)
packages: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/yaml/#environment # This is the documentation URL, but can be a URL to a video if there is one
available_in: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Starter, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/yaml/#environment # This is the documentation URL, but can be a URL to a video if there is one
image_url: https://about.gitlab.com/images/15_0/environment.png # 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: 2022-05-22 # YYYY-MM-DD
release: 15.0 # XX.Y

32
data/whats_new/202206220001_15_1.yml
View File

@ -9,30 +9,30 @@
#
# Please delete this line and above before submitting your merge request.
- title: SAML Group Sync for self-managed GitLab
body: | # Do not modify this line, instead modify the lines below.
- name: SAML Group Sync for self-managed GitLab
description: | # Do not modify this line, instead modify the lines below.
You can now map a group in your identity provider to a self-managed GitLab group using SAML group links. Previously, this feature was only available for GitLab.com. Group memberships are updated when a user logs into GitLab through their SAML provider. This new functionality decreases the workload for GitLab administrators and reduces onboarding time for group members.
stage: manage # String value of the stage that the feature was created in. e.g., Growth
self-managed: true
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/group/saml_sso/group_sync.html
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/group/saml_sso/group_sync.html
image_url: https://about.gitlab.com/images/15_1/SAML_Group_Sync.png # 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: 2022-06-22
release: 15.1
- title: Enhancing visibility into Value Stream with DORA metrics
body: | # Do not modify this line, instead modify the lines below.
- name: Enhancing visibility into Value Stream with DORA metrics
description: | # Do not modify this line, instead modify the lines below.
With the addition of the four [DORA metrics](https://docs.gitlab.com/ee/user/analytics/#devops-research-and-assessment-dora-key-metrics) tiles to the [Value Stream Analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/) dashboard, you can now track team performance and value flow from ideation to customer delivery. Additionally, we added a new trend chart for the DORA [Time to restore service](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html) metric to provide insights into software stability and reliability trends. This new chart shows information about how long it takes an organization to recover from a failure in production. This is the third DORA chart that's available out of the box in GitLab. We plan to keep improving the visibility into DORA metrics and also add charts for the fourth metric- Change failure rate.
stage: manage # String value of the stage that the feature was created in. e.g., Growth
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html
image_url: https://about.gitlab.com/images/15_1/vsa_dora_n_ttrs.png # 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: 2022-06-22
release: 15.1
- title: "SLSA-2 attestation included for build artifacts"
body: | # Do not modify this line, instead modify the lines below.
- name: "SLSA-2 attestation included for build artifacts"
description: | # Do not modify this line, instead modify the lines below.
[Supply-chain Levels for Software Artifacts (SLSA)](https://github.com/slsa-framework/slsa) is a security framework that helps ensure the security and integrity of your software supply chain. By default, GitLab Runner is now capable of generating and producing SLSA-2 compliant attestation metadata for build artifacts.
If the artifact is stored in a registry, then the attestation metadata is stored alongside the artifact in that registry. Otherwise, the metadata is in rendered in a plain text `.json` file that's stored with the artifact.
This new attestation information can help you more easily verify that your build artifacts have not been tampered with. To enable this feature, simply set `RUNNER_GENERATE_ARTIFACTS_METADATA = "true"` in your `.gitlab-ci.yml` file.
@ -40,20 +40,20 @@
stage: verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/runners/configure_runners.html#artifact-attestation
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/runners/configure_runners.html#artifact-attestation
image_url: https://img.youtube.com/vi/MlIdqrDgI8U/hqdefault.jpg
published_at: 2022-06-22
release: 15.1
- title: "Link to included CI/CD configuration from the pipeline editor"
body: | # Do not modify this line, instead modify the lines below.
- name: "Link to included CI/CD configuration from the pipeline editor"
description: | # Do not modify this line, instead modify the lines below.
A typical CI/CD configuration uses the `include` keyword to import configuration stored in other files or CI/CD templates. When editing or troubleshooting your configuration though, it can be difficult to understand how all the configuration works together because the included configuration is not visible in your `.gitlab-ci-yml`, you only see the `include` entry.
In this release, we added links to all included configuration files and templates to the pipeline editor. Now you can easily access and view all the CI/CD configuration your pipeline uses, making it much easier to manage large and complex pipelines.
stage: verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/pipeline_editor/
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/pipeline_editor/
image_url: https://img.youtube.com/vi/7BNDUYfY_ok/hqdefault.jpg
published_at: 2022-06-22
release: 15.1

56
data/whats_new/202207220001_15_2.yml
View File

@ -1,89 +1,89 @@
- title: "Live preview diagrams in the wiki WYSIWYG editor" # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: "Live preview diagrams in the wiki WYSIWYG editor" # Match the release post entry
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.
stage: create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/wiki/#use-the-content-editor
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/wiki/#use-the-content-editor
image_url: https://about.gitlab.com/images/15_2/create-preview-diagrams-in-wysiwyg.png
published_at: 2022-07-22
release: 15.2
- title: Incident timeline # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: Incident timeline # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
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.
stage: monitor
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/operations/incident_management/incidents.html#timeline-events
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/operations/incident_management/incidents.html#timeline-events
image_url: https://img.youtube.com/vi/a0brUwOajvQ/hqdefault.jpg
published_at: 2022-07-22
release: 15.2
- title: "Merge request reports redesign" # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: "Merge request reports redesign" # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
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.
stage: create
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/project/wiki/#use-the-content-editor
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/wiki/#use-the-content-editor
image_url: https://about.gitlab.com/images/15_2/create-merge-request-widget-redesign.png
published_at: 2022-07-22
release: 15.2
- title: "Change failure rate chart for visualizing software stability" # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: "Change failure rate chart for visualizing software stability" # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
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/).
stage: manage
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#view-change-failure-rate-chart
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#view-change-failure-rate-chart
image_url: https://about.gitlab.com/images/15_2/dora4_chart_cfr.png
published_at: 2022-07-22
release: 15.2
- title: "Enforce IP address restrictions for Git over SSH" # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: "Enforce IP address restrictions for Git over SSH" # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
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.
stage: create
self-managed: false
gitlab-com: true
packages: [Premium, Ultimate]
url: https://docs.gitlab.com/ee/user/group/#group-access-restriction-by-ip-address
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/group/#group-access-restriction-by-ip-address
image_url: https://img.youtube.com/vi/f60EgVK3mWc/hqdefault.jpg
published_at: 2022-07-22
release: 15.2
- title: "Group and subgroup scan execution policies" # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: "Group and subgroup scan execution policies" # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
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).
stage: protect
self-managed: true
gitlab-com: true
packages: [Ultimate]
url: https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html'
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html'
image_url: https://about.gitlab.com/images/15_2/protect_group_policies.png
published_at: 2022-07-22
release: 15.2
- title: "Set the image pull policy in pipeline configuration" # Match the release post entry
body: | # Do not modify this line, instead modify the lines below.
- name: "Set the image pull policy in pipeline configuration" # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
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.
stage: verify
self-managed: true
gitlab-com: true
packages: [Free, Premium, Ultimate]
url: https://docs.gitlab.com/ee/ci/yaml/#imagepull_policy
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/ee/ci/yaml/#imagepull_policy
image_url: https://about.gitlab.com/images/15_2/pull_policy.png
published_at: 2022-07-22
release: 15.2

8
data/whats_new/templates/YYYYMMDD0001_XX_YY.yml
View File

@ -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.
- name: # Match the release post entry
description: | # Do not modify this line, instead modify the lines below.
<!-- START OF BODY COMMENT
This area supports markdown.
@ -25,8 +25,8 @@
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., [Free, Premium, Ultimate]
url: # This is the documentation URL, but can be a URL to a video if there is one
available_in: # Array of strings. The Array brackets are required here. e.g., [Free, Premium, Ultimate]
documentation_link: # 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

16
lib/release_highlights/validator/entry.rb
View File

@ -5,16 +5,16 @@ module ReleaseHighlights
include ActiveModel::Validations
include ActiveModel::Validations::Callbacks
PACKAGES = %w(Free Premium Ultimate).freeze
AVAILABLE_IN = %w(Free Premium Ultimate).freeze
attr_reader :entry
validates :title, :body, :stage, presence: true
validates :name, :description, :stage, presence: true
validates :'self-managed', :'gitlab-com', inclusion: { in: [true, false], message: "must be a boolean" }
validates :url, :image_url, public_url: { dns_rebind_protection: true }
validates :documentation_link, :image_url, public_url: { dns_rebind_protection: true }
validates :release, numericality: true
validate :validate_published_at
validate :validate_packages
validate :validate_available_in
after_validation :add_line_numbers_to_errors!
@ -30,11 +30,11 @@ module ReleaseHighlights
errors.add(:published_at, 'must be valid Date')
end
def validate_packages
packages = value_for('packages')
def validate_available_in
available_in = value_for('available_in')
if !packages.is_a?(Array) || packages.empty? || packages.any? { |p| PACKAGES.exclude?(p) }
errors.add(:packages, "must be one of #{PACKAGES}")
if !available_in.is_a?(Array) || available_in.empty? || available_in.any? { |p| AVAILABLE_IN.exclude?(p) }
errors.add(:available_in, "must be one of #{AVAILABLE_IN}")
end
end

6
spec/fixtures/whats_new/20201225_01_01.yml vendored
View File

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

6
spec/fixtures/whats_new/20201225_01_02.yml vendored
View File

@ -1,7 +1,7 @@
---
- title: bright
body: |
- name: bright
description: |
## bright
self-managed: true
gitlab-com: false
packages: ["Premium", "Ultimate"]
available_in: ["Premium", "Ultimate"]

18
spec/fixtures/whats_new/20201225_01_04.yml vendored
View File

@ -1,19 +1,19 @@
---
- title: View epics on a board
body: |
- name: View epics on a board
description: |
## View epics on a board
self-managed: true
gitlab-com: false
packages: ["Free", "Premium", "Ultimate"]
- title: View Jira issue details in GitLab
body: |
available_in: ["Free", "Premium", "Ultimate"]
- name: View Jira issue details in GitLab
description: |
## View Jira issue details in GitLab
self-managed: true
gitlab-com: false
packages: ["Premium", "Ultimate"]
- title: Integrate any IT alerting tool with GitLab
body: |
available_in: ["Premium", "Ultimate"]
- name: Integrate any IT alerting tool with GitLab
description: |
## Integrate any IT alerting tool with GitLab
self-managed: true
gitlab-com: false
packages: ["Ultimate"]
available_in: ["Ultimate"]

12
spec/fixtures/whats_new/20201225_01_05.yml vendored
View File

@ -1,14 +1,14 @@
---
- title: bright and sunshinin' day
body: |
- name: bright and sunshinin' day
description: |
bright and sunshinin' [day](https://en.wikipedia.org/wiki/Day)
self-managed: true
gitlab-com: false
packages: ["Premium", "Ultimate"]
available_in: ["Premium", "Ultimate"]
release: '01.05'
- title: I think I can make it now the pain is gone
body: |
- name: I think I can make it now the pain is gone
description: |
## I think I can make it now the pain is gone
self-managed: false
gitlab-com: true
packages: ["Premium", "Ultimate"]
available_in: ["Premium", "Ultimate"]

4
spec/fixtures/whats_new/blank.yml vendored
View File

@ -1,5 +1,5 @@
- title:
body:
- name:
description:
stage:
self-managed:
gitlab-com:

16
spec/fixtures/whats_new/invalid.yml vendored
View File

@ -1,20 +1,20 @@
- 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.
- name: Create and view requirements in GitLab
description: 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: [ALL]
url: https://docs.gitlab.com/ee/user/project/requirements/index.html
available_in: [ALL]
documentation_link: https://docs.gitlab.com/ee/user/project/requirements/index.html
image_url: https://about.gitlab.com/images/press/logo/png/gitlab-icon-rgb.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.
- name: Retrieve CI/CD secrets from HashiCorp Vault
description: 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.
stage: Release
self-managed: true
gitlab-com: true
packages: [Free]
url: https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/index.html
available_in: [Free]
documentation_link: https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/index.html
image_url: https://about.gitlab.com/images/12_10/jwt-vault-1.png
published_at: 2020-04-22
release: 12.10

16
spec/fixtures/whats_new/valid.yml vendored
View File

@ -1,20 +1,20 @@
- 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.
- name: Create and view requirements in GitLab
description: 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]
url: https://docs.gitlab.com/ee/user/project/requirements/index.html
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/ee/user/project/requirements/index.html
image_url: https://about.gitlab.com/images/press/logo/png/gitlab-icon-rgb.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.
- name: Retrieve CI/CD secrets from HashiCorp Vault
description: 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.
stage: Release
self-managed: true
gitlab-com: true
packages: [Free]
url: https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/index.html
available_in: [Free]
documentation_link: https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/index.html
image_url: https://about.gitlab.com/images/12_10/jwt-vault-1.png
published_at: 2020-04-22
release: 12.10

4
spec/frontend/whats_new/components/app_spec.js
View File

@ -64,7 +64,7 @@ describe('App', () => {
buildWrapper();
wrapper.vm.$store.state.features = [
{ title: 'Whats New Drawer', url: 'www.url.com', release: 3.11 },
{ name: 'Whats New Drawer', documentation_link: 'www.url.com', release: 3.11 },
];
wrapper.vm.$store.state.drawerBodyHeight = MOCK_DRAWER_BODY_HEIGHT;
await nextTick();
@ -115,7 +115,7 @@ describe('App', () => {
it('renders features when provided via ajax', () => {
expect(actions.fetchItems).toHaveBeenCalled();
expect(wrapper.find('[data-test-id="feature-title"]').text()).toBe('Whats New Drawer');
expect(wrapper.find('[data-test-id="feature-name"]').text()).toBe('Whats New Drawer');
});
it('send an event when feature item is clicked', () => {

9
spec/frontend/whats_new/components/feature_spec.js
View File

@ -6,14 +6,15 @@ describe("What's new single feature", () => {
let wrapper;
const exampleFeature = {
title: 'Compliance pipeline configurations',
body:
name: 'Compliance pipeline configurations',
description:
'<p data-testid="body-content">We are thrilled to announce that it is now possible to define enforceable pipelines that will run for any project assigned a corresponding <a href="https://en.wikipedia.org/wiki/Compliance_(psychology)" target="_blank" rel="noopener noreferrer" onload="alert(xss)">compliance</a> framework.</p>',
stage: 'Manage',
'self-managed': true,
'gitlab-com': true,
packages: ['Ultimate'],
url: 'https://docs.gitlab.com/ee/user/project/settings/#compliance-pipeline-configuration',
available_in: ['Ultimate'],
documentation_link:
'https://docs.gitlab.com/ee/user/project/settings/#compliance-pipeline-configuration',
image_url: 'https://img.youtube.com/vi/upLJ_equomw/hqdefault.jpg',
published_at: '2021-04-22T00:00:00.000Z',
release: '13.11',

20
spec/lib/release_highlights/validator/entry_spec.rb
View File

@ -25,18 +25,18 @@ RSpec.describe ReleaseHighlights::Validator::Entry do
it 'returns line numbers in errors' do
subject.valid?
expect(entry.errors[:packages].first).to match('(line 6)')
expect(entry.errors[:available_in].first).to match('(line 6)')
end
end
context 'with a blank entry' do
it 'validate presence of title, body and stage' do
it 'validate presence of name, description and stage' do
subject.valid?
expect(subject.errors[:title]).not_to be_empty
expect(subject.errors[:body]).not_to be_empty
expect(subject.errors[:name]).not_to be_empty
expect(subject.errors[:description]).not_to be_empty
expect(subject.errors[:stage]).not_to be_empty
expect(subject.errors[:packages]).not_to be_empty
expect(subject.errors[:available_in]).not_to be_empty
end
it 'validates boolean value of "self-managed" and "gitlab-com"' do
@ -52,11 +52,11 @@ RSpec.describe ReleaseHighlights::Validator::Entry do
it 'validates URI of "url" and "image_url"' do
stub_env('RSPEC_ALLOW_INVALID_URLS', 'false')
allow(entry).to receive(:value_for).with(:image_url).and_return('https://foobar.x/images/ci/gitlab-ci-cd-logo_2x.png')
allow(entry).to receive(:value_for).with(:url).and_return('')
allow(entry).to receive(:value_for).with(:documentation_link).and_return('')
subject.valid?
expect(subject.errors[:url]).to include(/must be a valid URL/)
expect(subject.errors[:documentation_link]).to include(/must be a valid URL/)
expect(subject.errors[:image_url]).to include(/is blocked: Host cannot be resolved or invalid/)
end
@ -76,12 +76,12 @@ RSpec.describe ReleaseHighlights::Validator::Entry do
expect(subject.errors[:published_at]).to include(/must be valid Date/)
end
it 'validates packages are included in list' do
allow(entry).to receive(:value_for).with(:packages).and_return(['ALL'])
it 'validates available_in are included in list' do
allow(entry).to receive(:value_for).with(:available_in).and_return(['ALL'])
subject.valid?
expect(subject.errors[:packages].first).to include("must be one of", "Free", "Premium", "Ultimate")
expect(subject.errors[:available_in].first).to include("must be one of", "Free", "Premium", "Ultimate")
end
end
end

2
spec/lib/release_highlights/validator_spec.rb
View File

@ -70,7 +70,7 @@ RSpec.describe ReleaseHighlights::Validator do
---------------------------------------------------------
Validation failed for spec/fixtures/whats_new/invalid.yml
---------------------------------------------------------
* Packages must be one of ["Free", "Premium", "Ultimate"] (line 6)
* Available in must be one of ["Free", "Premium", "Ultimate"] (line 6)
MESSAGE
end

14
spec/models/release_highlight_spec.rb
View File

@ -28,7 +28,7 @@ RSpec.describe ReleaseHighlight, :clean_gitlab_redis_cache do
let(:page) { 3 }
it 'responds with paginated results' do
expect(subject[:items].first['title']).to eq('bright')
expect(subject[:items].first['name']).to eq('bright')
expect(subject[:next_page]).to eq(4)
end
end
@ -37,7 +37,7 @@ RSpec.describe ReleaseHighlight, :clean_gitlab_redis_cache do
let(:page) { 4 }
it 'responds with paginated results and no next_page' do
expect(subject[:items].first['title']).to eq("It's gonna be a bright")
expect(subject[:items].first['name']).to eq("It's gonna be a bright")
expect(subject[:next_page]).to eq(nil)
end
end
@ -63,12 +63,12 @@ RSpec.describe ReleaseHighlight, :clean_gitlab_redis_cache do
it 'returns platform specific items' do
expect(subject[:items].count).to eq(1)
expect(subject[:items].first['title']).to eq("bright and sunshinin' day")
expect(subject[:items].first['name']).to eq("bright and sunshinin' day")
expect(subject[:next_page]).to eq(2)
end
it 'parses the body as markdown and returns html, and links are target="_blank"' do
expect(subject[:items].first['body']).to match('<p data-sourcepos="1:1-1:62" dir="auto">bright and sunshinin\' <a href="https://en.wikipedia.org/wiki/Day" rel="nofollow noreferrer noopener" target="_blank">day</a></p>')
it 'parses the description as markdown and returns html, and links are target="_blank"' do
expect(subject[:items].first['description']).to match('<p data-sourcepos="1:1-1:62" dir="auto">bright and sunshinin\' <a href="https://en.wikipedia.org/wiki/Day" rel="nofollow noreferrer noopener" target="_blank">day</a></p>')
end
it 'logs an error if theres an error parsing markdown for an item, and skips it' do
@ -83,7 +83,7 @@ RSpec.describe ReleaseHighlight, :clean_gitlab_redis_cache do
it 'responds with a different set of data' do
expect(subject[:items].count).to eq(1)
expect(subject[:items].first['title']).to eq("I think I can make it now the pain is gone")
expect(subject[:items].first['name']).to eq("I think I can make it now the pain is gone")
end
end
@ -171,7 +171,7 @@ RSpec.describe ReleaseHighlight, :clean_gitlab_redis_cache do
items = described_class.load_items(page: 2)
expect(items.count).to eq(1)
expect(items.first['title']).to eq("View epics on a board")
expect(items.first['name']).to eq("View epics on a board")
end
end
end