diff options
Diffstat (limited to 'data/whats_new')
29 files changed, 767 insertions, 678 deletions
diff --git a/data/whats_new/202008180001_12_10.yml b/data/whats_new/202008180001_12_10.yml index a21e9d795a1..aa53a2f6140 100644 --- a/data/whats_new/202008180001_12_10.yml +++ b/data/whats_new/202008180001_12_10.yml @@ -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 diff --git a/data/whats_new/202008180002_13_0.yml b/data/whats_new/202008180002_13_0.yml index e82fa82cae0..930c4245ea5 100644 --- a/data/whats_new/202008180002_13_0.yml +++ b/data/whats_new/202008180002_13_0.yml @@ -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 diff --git a/data/whats_new/202008180003_13_01.yml b/data/whats_new/202008180003_13_01.yml index 835b0f8567b..d3ae61e3be5 100644 --- a/data/whats_new/202008180003_13_01.yml +++ b/data/whats_new/202008180003_13_01.yml @@ -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 diff --git a/data/whats_new/202008210001_13_02.yml b/data/whats_new/202008210001_13_02.yml index ce562abbf29..55e2608108a 100644 --- a/data/whats_new/202008210001_13_02.yml +++ b/data/whats_new/202008210001_13_02.yml @@ -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 diff --git a/data/whats_new/202009150001_13_03.yml b/data/whats_new/202009150001_13_03.yml index e9d63561af8..100c615f974 100644 --- a/data/whats_new/202009150001_13_03.yml +++ b/data/whats_new/202009150001_13_03.yml @@ -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 diff --git a/data/whats_new/202009300001_13_04.yml b/data/whats_new/202009300001_13_04.yml index 4ba278def0c..a86defd61c5 100644 --- a/data/whats_new/202009300001_13_04.yml +++ b/data/whats_new/202009300001_13_04.yml @@ -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 diff --git a/data/whats_new/202010230001_13_05.yml b/data/whats_new/202010230001_13_05.yml index 9166d148b37..e68d89db669 100644 --- a/data/whats_new/202010230001_13_05.yml +++ b/data/whats_new/202010230001_13_05.yml @@ -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 diff --git a/data/whats_new/202011230001_13_06.yml b/data/whats_new/202011230001_13_06.yml index 1e47bcca0ec..effaa243812 100644 --- a/data/whats_new/202011230001_13_06.yml +++ b/data/whats_new/202011230001_13_06.yml @@ -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 diff --git a/data/whats_new/202012160001_13_07.yml b/data/whats_new/202012160001_13_07.yml index 28d596081cc..6b07bd4341a 100644 --- a/data/whats_new/202012160001_13_07.yml +++ b/data/whats_new/202012160001_13_07.yml @@ -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 diff --git a/data/whats_new/202101140001_13_08.yml b/data/whats_new/202101140001_13_08.yml index 3a1c0179d84..084d09a18e4 100644 --- a/data/whats_new/202101140001_13_08.yml +++ b/data/whats_new/202101140001_13_08.yml @@ -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 diff --git a/data/whats_new/202102180001_13_09.yml b/data/whats_new/202102180001_13_09.yml index 5f50a05bef2..ee097583884 100644 --- a/data/whats_new/202102180001_13_09.yml +++ b/data/whats_new/202102180001_13_09.yml @@ -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 diff --git a/data/whats_new/202103220001_13_10.yml b/data/whats_new/202103220001_13_10.yml index a1f456a6c8d..bba60a60ca2 100644 --- a/data/whats_new/202103220001_13_10.yml +++ b/data/whats_new/202103220001_13_10.yml @@ -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 diff --git a/data/whats_new/202104220001_13_11.yml b/data/whats_new/202104220001_13_11.yml index 6453893b6de..7a3bb433340 100644 --- a/data/whats_new/202104220001_13_11.yml +++ b/data/whats_new/202104220001_13_11.yml @@ -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 diff --git a/data/whats_new/202105220001_13_12.yml b/data/whats_new/202105220001_13_12.yml index bbe614959a0..893ea694988 100644 --- a/data/whats_new/202105220001_13_12.yml +++ b/data/whats_new/202105220001_13_12.yml @@ -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 diff --git a/data/whats_new/202106220001_14_0.yml b/data/whats_new/202106220001_14_0.yml index a17261e8586..62bb78cecbb 100644 --- a/data/whats_new/202106220001_14_0.yml +++ b/data/whats_new/202106220001_14_0.yml @@ -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 diff --git a/data/whats_new/202107220001_14_1.yml b/data/whats_new/202107220001_14_1.yml index 881d96c58d3..32764b98803 100644 --- a/data/whats_new/202107220001_14_1.yml +++ b/data/whats_new/202107220001_14_1.yml @@ -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 diff --git a/data/whats_new/202108190001_14_02.yml b/data/whats_new/202108190001_14_02.yml index 99ba097b60c..bb9c8becd06 100644 --- a/data/whats_new/202108190001_14_02.yml +++ b/data/whats_new/202108190001_14_02.yml @@ -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 diff --git a/data/whats_new/202109200001_14_03.yml b/data/whats_new/202109200001_14_03.yml index fa0f05bf0a0..59d2655f072 100644 --- a/data/whats_new/202109200001_14_03.yml +++ b/data/whats_new/202109200001_14_03.yml @@ -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 diff --git a/data/whats_new/2021102000001_14_04.yml b/data/whats_new/2021102000001_14_04.yml index 13caddd2bc5..3342be0c34f 100644 --- a/data/whats_new/2021102000001_14_04.yml +++ b/data/whats_new/2021102000001_14_04.yml @@ -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 diff --git a/data/whats_new/2021111800001_14_05.yml b/data/whats_new/2021111800001_14_05.yml index 71f4b0245b9..967d8b05cfa 100644 --- a/data/whats_new/2021111800001_14_05.yml +++ b/data/whats_new/2021111800001_14_05.yml @@ -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 diff --git a/data/whats_new/202112200001_14_06.yml b/data/whats_new/202112200001_14_06.yml index 178cc4dc019..c0d6426209f 100644 --- a/data/whats_new/202112200001_14_06.yml +++ b/data/whats_new/202112200001_14_06.yml @@ -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 diff --git a/data/whats_new/202201200001_14_07.yml b/data/whats_new/202201200001_14_07.yml index d8c76334775..2b389621253 100644 --- a/data/whats_new/202201200001_14_07.yml +++ b/data/whats_new/202201200001_14_07.yml @@ -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 diff --git a/data/whats_new/202202210001_14_08.yml b/data/whats_new/202202210001_14_08.yml index 930535dd4e0..206fec03359 100644 --- a/data/whats_new/202202210001_14_08.yml +++ b/data/whats_new/202202210001_14_08.yml @@ -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 diff --git a/data/whats_new/202203210001_14_09.yml b/data/whats_new/202203210001_14_09.yml index 05a5899d751..027f42fda1b 100644 --- a/data/whats_new/202203210001_14_09.yml +++ b/data/whats_new/202203210001_14_09.yml @@ -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 diff --git a/data/whats_new/202204210001_14_10.yml b/data/whats_new/202204210001_14_10.yml index 2f3d32bd87c..c4028662f59 100644 --- a/data/whats_new/202204210001_14_10.yml +++ b/data/whats_new/202204210001_14_10.yml @@ -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 diff --git a/data/whats_new/202205220001_15_0.yml b/data/whats_new/202205220001_15_0.yml index 8aa09d442c8..e1449f13c0a 100644 --- a/data/whats_new/202205220001_15_0.yml +++ b/data/whats_new/202205220001_15_0.yml @@ -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 diff --git a/data/whats_new/202206220001_15_1.yml b/data/whats_new/202206220001_15_1.yml index 76ef7fd1a46..ab91ffeecb6 100644 --- a/data/whats_new/202206220001_15_1.yml +++ b/data/whats_new/202206220001_15_1.yml @@ -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 - image_url: https://www.youtube.com/embed/MlIdqrDgI8U + 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/ - image_url: https://www.youtube.com/embed/7BNDUYfY_ok + 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 diff --git a/data/whats_new/202207220001_15_2.yml b/data/whats_new/202207220001_15_2.yml new file mode 100644 index 00000000000..4f6f65c9f18 --- /dev/null +++ b/data/whats_new/202207220001_15_2.yml @@ -0,0 +1,89 @@ +- 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 + 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 +- 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 + 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 +- 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 + 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 +- 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 + 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 +- 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 + 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 +- 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 + 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 +- 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 + 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 diff --git a/data/whats_new/templates/YYYYMMDD0001_XX_YY.yml b/data/whats_new/templates/YYYYMMDD0001_XX_YY.yml index 31d2312809d..691db083301 100644 --- a/data/whats_new/templates/YYYYMMDD0001_XX_YY.yml +++ b/data/whats_new/templates/YYYYMMDD0001_XX_YY.yml @@ -9,8 +9,8 @@ # # Please delete this line and above before submitting your merge request. -- title: # Match the release post entry - body: | # Do not modify this line, instead modify the lines below. +- 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 |