GitLab’s child/parent pipelines let you write your own code to generate an entire pipeline YAML. This is a powerful way to generate custom behaviors, including generating jobs at runtime. This might not be needed for simpler scenarios where you just want to create multiple similar jobs for a defined set of cases. In this release you can find a new
matrix keyword that works along with
parallel to handle the creation of multiple jobs for you, each with different variables.
For example, you could configure your pipeline to automatically create jobs for 4 different architectures, each with a
release target for 3 different versions, all with a single matrix-style configuration. This would create 24 unique jobs (4x2x3) to cover every possible combination.
Dynamic Application Security Testing at GitLab has always been focused on integrating DAST into the DevOps pipeline and enabling developers to scan their review app, running website, or API for vulnerabilities as early as possible. However, there are times when it is necessary to run a DAST scan against an already deployed application when no code changes have been made and no Merge Request has been created. These scans could be needed for audit or compliance reasons, to debug and reproduce an issue that has been found, or to support teams who do not commit code, such as security analysts. Because of the need for DAST scans that are not triggered by a code change or MR, on-demand DAST testing is now available. You don’t need configuration files or code to start running on-demand scans. Configuration options for on-demand DAST scans are available within the GitLab UI. The result is quicker configuration and greatly improved ease of use. When starting a new on-demand scan you select from a site profile that contains your preferred settings. In 13.3, we are releasing the first iteration of the on-demand scans. These scans will initially be limited to a 60-second spider time and a passive DAST scan. This scan will give a quick reconnaissance-type overview of the site you are scanning, without causing any performance or security issues. Over the next few releases, we will be adding options to the Site profile and introducing the Scanner profile. These additions will allow you to increase the spider time, validate ownership of the target site, enable active scans, set authentication options, and more.
We want to help developers write better code and worry less about common security mistakes. Static Application Security Testing (SAST) helps prevent security vulnerabilities by allowing developers to easily identify common security issues as code is being committed and mitigate proactively. As part of our community stewardship commitment we have made all 15 of our open source based SAST analyzers available in every GitLab tier. This allows ALL GitLab users developing in any of our 18 supported languages and frameworks to leverage GitLab SAST in their projects.
Getting started is as easy as using our new guided SAST configuration experience, enabling Auto DevOps, or adding the SAST configuration template to your
gitlab-ci.yml file. Customers not on the Ultimate tier can interact with generated SAST vulnerability report by downloading the SAST job artifact. We’ve also updated our docs with details about the tier breakdown for all our SAST features.
GitLab’s Static Application Security Testing (SAST) now supports a new guided configuration experience. Enabling SAST is now as simple as two clicks. We believe that security is a team effort and this configuration experience makes it easier for non-CI experts to get started with GitLab SAST. The tool helps a user create a merge request to enable SAST scanning while leveraging best configuration practices like using the GitLab-managed
SAST.gitlab-ci.yml template and properly overriding template settings.
With GitLab SAST covering 18 languages across 14 analyzers, there are many SAST configuration options and it can be hard to understand and setup. This new guided SAST configuration experience helps anyone get started with SAST, and lays the foundation for us to introduce new configuration options like custom rulesets and more. We also intend to expand this guided experience to our other security scanning tools.
Seeing all of your system’s metrics in one place, including cluster metrics, is critical for understanding the health of your system. In GitLab 13.3, you can view the health of your Kubernetes pods in the new out-of-the-box Pod health metrics dashboard, whether you are using a managed Prometheus, or have an existing instance of Prometheus running in your cluster, by connecting it to your GitLab instance. Select the desired pod in the dropdown and see key metrics such as CPU, memory usage, Network, and more.
Code review often involves multiple people and multiple iterations. It can be hard to know who has been reviewing the merge request, and which of those reviewers has approved and who hasn’t. It is important so you can avoid duplicating work and wasting time.
To show who has provided feedback via comments, the merge request widget now shows a Commented by column. This makes it easier for authors and reviewers to identify who to engage.
With the introduction of support for multiple strategies per feature flag in GitLab 13.0, you are able to set strategies for your feature flags. However, you were unable to see the relevant strategy information in the list view of feature flags. It’s now possible to see all related information about a feature flag in the list view. This includes the strategies, the environments, and the number or percent of users for which the flag is enabled. This view lets you quickly understand the configuration of all the flags in your project without the need to open each one of them individually.
Administrators of self-managed GitLab can now integrate third-party services with all projects on the instance from a single interface.
Previously, integrations had to be configured per project, which meant that if an instance had thousands of projects, thousands of individual configurations had to be manually configured. Not only was this time-consuming, but it was also error-prone, hard to update, and made it difficult to enforce integrations as a policy.
By configuring integrations across all projects, administrators save themselves and their project owners incredible amounts of time and effort.
This is the first iteration of this functionality. In upcoming releases, we will expand this feature to the group level, add more configuration and compliance options, and more.
Investigating incidents requires on-call engineers to evaluate different data sources across multiple tools. Assessing metrics, logs, and traces, sharing findings, and updating stakeholders requires engineers to manually aggregate information through screengrabs, copying, and pasting. This work is inefficient and time-consuming, which leads to alert fatigue, increased stress, and low morale.
In 13.3, GitLab is excited to introduce a dedicated list for triaging and managing Incidents in the Operations section of GitLab to help you reduce resolution time. The Incident list provides a high-level summary of the incident, and critical details: when it was created, who is assigned, and the Status Page publication state. Additionally, there are different views organized by status (open, closed, and all) making it easy to identify active incidents.
In GitLab 13.4 and beyond we plan to improve incident response workflows by surfacing related metrics charts, embedding logs, and rendering associated runbooks. To view progress and suggest ideas for future improvements, see the Incident Management epic.
A year and a half ago, we expanded our support for Java projects and developers by building Maven support directly into GitLab. Our goal was to provide a standardized way to share packages and have version control across projects. Since then, we’ve invested to build out the Package team further while working with our customers and community to better understand your use cases. We also added support for Node, C#/.NET, C/C++, Python, PHP, and Go developers. Your increased adoption, usage, and contributions to these features have allowed us to expand our vision to a more comprehensive solution, integrated into our single application, which supports package management for all commonly-used languages and binary formats. This goal could not have been achieved without the explicit support of the GitLab community.
As part of GitLab’s stewardship promises, we are excited to announce that the basic functionality for each package manager format is now available in the GitLab Core Edition. This means that if you use npm, Maven, NuGet, Conan, PyPI, Composer or Go modules, you will be able to:
- Use GitLab as a private (or public) package registry
- Authenticate using your GitLab credentials, personal access, or job token
- Publish packages to GitLab
- Install packages from GitLab
- Search for packages hosted on GitLab
- Access an easy-to-use UI that displays package details and metadata and allows you to download any relevant files
- Ensure that your contributions are available for ALL GitLab users
We look forward to hearing your feedback and continuing to improve these features with all of our users.
Over two years ago, Fatih Acet created an extension to integrate GitLab with development in Visual Studio Code. Fatih and more than 25 contributors continued to improve the extension with new features, and it has now been installed over 160,000 times. Fatih transferred maintainership to GitLab, and we’ll continue to improve and support this extension.
The GitLab Workflow is now officially maintained and supported by the Editor Group. We’ll be continuing to contribute features, and support the community who was actively involved in our early releases. If you have ideas or feedback, please open an issue.
As a project maintainer, you might want to enable contributions from forked projects that are fully tested by your own project’s CI/CD pipeline. Previously, you’d have to give contributors access to project CI runners, CI configuration, and CI variables, which is something many development groups aren’t comfortable doing. Now, GitLab allows parent project members with the appropriate permissions to run a pipeline for an MR submitted from a fork using the parent project’s CI/CD configuration. It also shows a warning dialog explaining the risks before starting the pipeline so you can better mitigate potential risks.
Today, GitLab’s ECS deployment template updates existing task definitions that are already defined in your attached AWS account. It’s also common to update your task-definition as part of your GitLab flow. Now, you can update the JSON task definition in your local repository and push it knowing the task will get appropriately created in the AWS account, improving your standard development flow.
Project level access tokens allow access to a project without the need to provision a new GitLab user. Project access tokens can be generated by project Maintainers or Owners and be used to authenticate with the GitLab API. Project access tokens will be authorized as Maintainers. This new functionality will make programmatic access to GitLab easier and more secure.
You may have noticed the new DAG tab on your pipelines that visually renders the directed acyclic graph dependencies for pipelines using the
needs keyword. This makes it easier to understand complex webs of dependencies in your CI/CD configuration. In this release, we consider the feature officially released and are removing the beta tag! Your feedback is still welcome, as always, so let us know what you think.
You can now create, edit, and delete Feature Flag user lists directly in the UI. Previously, you could only perform these actions via the API. Add or remove users to the list quickly and easily, as well as change the name of the list.
Commenting on a specific line in a merge request diff is a great way to leave feedback for the author. Reviewers often need to comment on an entire section of the code, for example a function or expression which covers multiple lines of code. Leaving a comment on a single line, while referring to many lines, makes communication less clear and less efficient.
With the introduction of multi-line comments, reviewers will no longer need to decide which single line of code to choose during a review, instead they will be able to provide feedback to multiple lines in the merge request diff.
Future iterations will include multi-line suggestions as well as increased ease of use. You can follow along in the multi-line comments epic.