GitLab 13.3 released with coverage-guided fuzz testing and a build matrix for CI/CD
GitLab 13.3 released with on-demand DAST, MR Analytics, Compliance dashboard, Pod health dashboard and much more!
DevSecOps helps teams detect and resolve faults and vulnerabilities early in the software development process. In GitLab 13.3, building secure software is easier with fuzz testing in your development workflow. With coverage-guided fuzz testing and on-demand DAST (Dynamic Application Security Testing), discovering real-world software vulnerabilities is faster and more efficient. At the same time, releasing code more frequently is made simpler with the new build matrix for CI/CD. Finally, the Pod health dashboard increases Ops' efficiency by reducing their context switching: all Kubernetes pods health primitives are in the dashboard. We hope that you find these top features, and the 69 new features packed in this release, useful.
Faster remediation: Find and prevent defects and vulnerabilities earlier
With coverage-guided fuzz testing, it's now easier to efficiently surface and solve vulnerabilities in C, C++, and Go. In GitLab 13.3 all our SAST (Static Application Security Testing) analyzers are available to everyone and it has never been easier to set them up. Finally, running DAST from the GUI is now more convenient. More importantly, security staff can tackle vulnerabilities faster by leveraging the new vulnerability evidence included in the DAST output.
Reduce cycle time, release more frequently
Building powerful workflows is now easy with the new build matrix: define keys and values once, release and deploy multiple times. Teams can increase velocity by measuring Merge Request throughput now available in the MR Analytics Dashboard. Also, MR authors can now integrate code faster by acknowledging their code review requests have been answered at a glance. This acknowledgment of fulfilled duties by different roles in MRs are now traceable in the Compliance Dashboard. Maintainers can also suggest to their contributors a Squash Commit policy. Lastly, rollouts can be more targeted and controlled using the newly named feature flags strategy called Percentage of Users.
Enable your delivery teams to be more productive and efficient
Software development is mostly about building and distributing packages. To make that easier and with usability in mind, we overhauled the whole Package registry GUI and made it available for everyone in Core. Plus, it has never been easier to publish NuGet packages in an automated way. Once deployed, your teams won't need to worry about the health of their systems. All relevant action can be now taken based on information from the Pod health dashboard.
It doesn’t stop here: there is more!
GitLab is used by companies with thousands of users in teams working synchronously and asynchronously across continents. To do so, we are focused on improving its fault tolerance and read/write operation synchronicity on every release. Overall, we are making GitLab lightning fast across the globe.
Here are several other cool features that you should check out:
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.
This is the first release that incorporates the new technology from the fuzz
testing acquisitions we recently announced.
We recently wrote a blog post
with some more information about the acquisitions as well.
We have much more on the way for fuzz testing. Check out all the details on our
fuzz testing direction page
page. We’d love for you to let us know what you think!
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 debug and 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.
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.
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.
Organizations need visibility into the compliance status of their groups and projects. A major component of compliance is the merge request; it is often the primary gating mechanism to ensure the appropriate policy and process has been followed. As such, one of the most important details of a merge request to highlight is to indicate the separation of duties between author and approver.
Now, within the Compliance Dashboard, you can view both the merge request author and the approver(s), enabling you to more quickly hone in on the projects that may not have maintained separation of duties.
Many organizations, including GitLab, use throughput as
a way of measuring how fast a team can do work. We’re now introducing
a first iteration of Merge Request Analytics to help your team better understand the rate of merged MRs in your projects.
Available at the project level, Merge Request Analytics can help an engineering team quickly understand MR activity at a glance.
Users interested in a more detailed look—for example, a team lead interested in MRs with a specific label—are also able
to filter and see a detailed list of relevant MRs.
Group administrators can now prevent the projects within their group from having new forks created outside of the current top-level group. This new setting gives group administrators additional mechanisms to protect their group’s intellectual property.
Reviewing merge requests diffs is an essential task when reviewing code
contributions, as this is where most of the communication between author and
reviewer takes place. However, as merge requests become larger and more files
are involved, navigation and performance of merge request diffs can become difficult.
To resolve this, GitLab 13.3 introduces an option to see one file
at a time on the Changes tab of merge requests. It provides a cleaner
workspace and enhances the reviewer focus on one single file. At the
bottom, you can navigate between the files changed by clicking the
Prev and Next buttons. It can be optionally enabled through user
preferences.
Thanks to GitLab user Osher for contributing
to the initial iteration.
Backups protect against data loss events and should be run regularly, and before maintenance and upgrades. For this reason, GitLab has a gitlab-backup script so that system administrators can back up everything. As the number and size of repositories increases, backing up repository data using the script becomes impossibly slow.
A significant reason why the script is slow is that repositories are backed up one by one. This underutilizes the available CPU and memory resources, particularly when there are multiple Gitaly nodes. Adding concurrency allows multiple repositories to be backed up at the same time, significantly reducing backup time.
If you are using GitLab to design a product with screens or a user flow, you’ll want to place your designs in a specific sequence to present the full concept to your team.
Previously, designs were only displayed in the order in which they were uploaded, complicating reviews and leading to frustration.
As of 13.3, you can now drag and drop your designs into any order! The order is saved so that anyone who views your designs will see the order you intended. Go forth and create the flows you imagine or re-order to match your frames in Figma or Sketch!
Code review is an important process that requires an understanding of the proposed change and surrounding code to know if it has been made in a maintainable way. GitLab’s native Code Intelligence helps developers navigate code and understand changes introduced in merge requests. This is important to understand existing code as well to ensure new code is added in a responsible way.
GitLab 13.3 introduces the ability to display references for projects using GitLab’s native Code Intelligence. Clicking on an object in your code will display the definition and offer the ability to browse references on the second tab, displaying the full path and line number where the object is being used.
Future iterations will include API support and displaying the code for references in the popover. You can follow along in the Code Intelligence epic.
Gitaly Cluster allows Git repositories to be replicated on multiple warm Gitaly nodes. This improves fault tolerance by removing single points of failure. Write operations are currently replicated asynchronously however, which means that the GitLab server only has one copy of the change from when the write is accepted, until replication is complete.
Transactional write operations to Git repositories in GitLab 13.3 causes changes to be broadcast to all Gitaly nodes. Only the Gitaly nodes that vote in agreement with the primary node persist the changes to disk. Dissenting nodes are brought in sync by asynchronous replication. This means the change will typically be written to all Gitaly nodes when the write is accepted. This is not guaranteed, however, because all replica nodes could vote against the primary. Quorum-based voting (beta) can be enabled to prevent this.
Note: Gitaly Clusters can be created using GitLab Core and higher tiers. However, technical support is limited to GitLab Premium and Ultimate customers only.
Gitaly Cluster allows Git repositories to be replicated on multiple warm Gitaly nodes. This improves fault tolerance by removing single points of failure. However, because write operations are currently replicated asynchronously, the GitLab server only has one copy of the change initially.
In GitLab 13.2, transactional write operations to Git repositories can be enabled for Gitaly Cluster. When this option is enabled and an update is pushed to GitLab, the write operation will be proxied to the replica Gitaly nodes. The write operation will be coordinated between the Gitaly nodes using the two-phase commit protocol, so that they agree on the new state of the repository. Write transactions are currently limited to operations pushed over the HTTP and SSH Git interfaces, and does not include write operations via the GitLab interface like the Web IDE.
When you can’t track changes to CI/CD variables, it’s difficult to understand what might have caused your pipeline to fail. Now, in our first iteration of variable audit logs, you can track changes to group-level CI/CD variables. This new audit log captures three events: group variable additions, removals, and protected state changes.
The CI linter can now provide warnings in addition to error messages when validating your .gitlab-ci.yml file. This gives us the opportunity to provide more guidance when evaluating your pipelines, thereby making it easier to avoid more kinds of mistakes by catching them earlier.
Our initial iteration is to provide a warning when the when:always rule is used without workflow:rules; this scenario causes duplicate pipelines when an MR is created and has also been a source of confusion. And in addition to displaying this new warning message on the linter page, it will also appear on the pipeline view and run pipeline page to help you improve your CI configurations.
As a developer, you have the ability to specify a job artifact’s exact expiration date, but there are scenarios where you may need to retain an artifact forever. Now, you can set an artifact to never expire by setting the value of expire_in to never in your CI configuration.
We introduced the Fail Fast Testing template in GitLab 13.1 and gathered feedback from internal stakeholders. We found that if the default image was being overridden in a .gitlab-ci.yml file, the template would not work. We’ve since improved the Fail Fast template so you can now trust the Fail Fast Template to work out of the box, even if you specify a different image.
We’ve added a new group management user interface (UI) for managing your organization’s Runners. In this new UI, you can view, edit, pause, and stop any Runner that’s associated with your group in GitLab. This makes it easier to troubleshoot potential issues with Runners for multiple projects at once.
You can use the GitLab NuGet Repository to build, publish, and share .NET packages, right alongside your source code and CI/CD Pipelines. However, previously you couldn’t authenticate with the repository by using the pre-defined environment variable CI_JOB_TOKEN. As a result, you were forced to use your personal credentials for making updates to the NuGet Repository, or you may have decided not to use the repository at all.
Now it is easier than ever for you to use GitLab CI/CD to publish and install NuGet packages using the pre-defined CI_JOB_TOKEN environment variable.
In an effort to simplify the Feature Flag strategies and prevent confusion we have renamed them. Percent rollout (logged in users) has been changed to Percent of users and List has been changed to User List.
This feature expands on the API capability of setting a deploy freeze window, which we introduced in 13.0. Now, from the GitLab UI, you can easily set a time period when deployments can’t occur. You no longer have to use the API to script your deploy freeze or use .gitlab-ci.yml. Instead, you can easily go to the UI settings to create a recurring or one-time deploy freeze.
You can now configure GitLab Pages to source a project’s configuration through the GitLab internal API, and take advantage of the API for quicker GitLab Pages daemon booting times.
You can now generate GitLab issues from PagerDuty incidents, automatically notifying your responders when alerts are triggered, and centralizing your responses within GitLab.
When you receive alerts, GitLab helps you reduce investigation time by including the relevant metrics chart in the alert, helping you visualize what went wrong. In GitLab 13.3, we are introducing including metrics from an externally managed Prometheus instance within the alert.
When maintaining the availability and reliability of a service, you don’t always learn of problems from your alerting systems: customers report outages, or team members spot anomalies. Regardless of the source, you can now manually create Incidents from the Incident List to mobilize your response teams when you learn of a problem.
Previously, dashboard actions such as creating, editing, duplicating, and adding metrics were scattered across the metrics dashboard. GitLab 13.3 organizes these items into a single actions menu, simplifying access to dashboard management features.
Vulnerabilities that have been found by a DAST scan can be difficult to reproduce, since the vulnerability might be reproduced only under certain circumstances. It can also be difficult to pinpoint what code is responsible for the issue when attempting to fix it. Evidence of the vulnerability discovered by the DAST scan is now included in the vulnerability details, making reproduction and remediation easier.
Container Network Policy Controls provide an easily discoverable way to find
the documentation on how to install and uninstall Container Network Policies
for a Kubernetes cluster. You can access these controls, along
with a visual indicator of the current Container Network Policies status,
in the Operations > Kubernetes > Applications page’s new
GitLab Container Network Policies section.
It is now possible to configure a dependency proxy for upstream images/packages in the GitLab Helm chart. Note that backup and restore, and migration from Omnibus are not currently supported. To learn more about dependency proxy, see Dependency Proxy. For configuration instructions, see Configure Charts using Globals.
The settings to configure object storage have been consolidated so that object storage for all objects can be configured by one section in values.yml. This is a great improvement that makes object storage configuration much more efficient, including the ability to use a single credential for multiple S3 buckets. It also enables GitLab Workhorse to upload files directly with its own S3 client, eliminating the need for pre-signed URLs. For more details, refer to the Object Storage documentation.
For improved aggregation, the Workhorse log is now output in JSON rather than as unstructured data. For more details, see the related issue.
PostgreSQL 12 is now supported as an opt-in PostgreSQL version for self-managed installations of GitLab. PostgreSQL 12 includes a number of performance improvements such as improved query performance for large data sets. For a full list of improvements, see the PostgreSQL release page. Support for using PostgreSQL 12 with a PostgreSQL cluster and Geo sites will be coming soon. For more details on support for PostgreSQL 12 in GitLab, see the PostgreSQL 12 epic. PostgreSQL 12 is scheduled to become the default version of PostgreSQL in GitLab 13.6, but it will still be possible to opt out of this version.
One of the common tasks users perform in the GitLab UI is viewing rich content, for example
rendered markdown in an issue, a merge request, or just viewing a file. For large content, this
can take a long time to complete, resulting in a lengthy wait.
In GitLab 13.3, we have optimized how this content is generated, improving user experience and reducing load on the server.
The GitLab changelog, a 14,000 line markdown file,
now takes 20 seconds to view instead of 35, for a 40% improvement!
Unfurling a URL in tools like Slack provides useful context for other team members. In GitLab 13.3, search result pages have updated meta headers to provide a better description when unfurled.
In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!
Some notable performance improvements in GitLab 13.3 are:
In this release, we’re making customizable Value Stream Analytics (VSA)
even better by allowing teams to create multiple custom value streams. Customizability in VSA allows teams to have detailed understanding of a group’s
activity, and you’re now able to create and reuse your customized stages in this feature without needing to re-create them each time.
This is ideal for projects and groups collaborating across multiple departments, where each department may measure value differently. A project manager may
want to see a value stream defined by issue labels, but an engineering team may want to understand merge request activity and time to deploy. With multiple value
streams, you’re now able to create and customize separate value streams for both.
We have improved the logic for unknown sign-in email notifications so that users receive fewer emails. We recommend leaving unknown sign-in email notifications enabled, but GitLab administrators will now also have the option to disable unknown sign-in email notifications for their instance. This option can be used in cases where users cannot accept cookies in their browser and users’ IPs change often.
To simplify the group member onboarding flow, GitLab 13.3 introduces the ability for group owners to set any role as the ‘Default membership role’ for users added to the group by SSO or SCIM. Previously all group members added to the group by SSO or SCIM were assigned the ‘Guest’ role by default.
As confidential work becomes ready to be shared on a more public level, it can be difficult to share a collection of issues
and their parent epic. You can now toggle the confidentiality of your epics, enabling or disabling visibility for those with the proper access.
Static site generators often rely on Markdown to organize content and the Static Site Editor offers an intuitive WYSIWYG Markdown editing experience for those documents. However, their content isn’t always written in Markdown. Many generators support additional markup embedded in the Markdown to extend the author’s capabilities. It is also valid to write HTML alongside markdown content.
The Static Side Editor’s WYSIWYG mode now separates non-Markdown content into uneditable content blocks, displayed inline with your content. This prevents unexpected formatting errors that can arise when the editor attempts to convert non-Markdown content to HTML. The non-Markdown content is still editable in the raw source mode of the Static Site Editor and future iterations will enable safely editing this kind of content within the WYSIWYG mode.
We’ve upgraded the web editor to a lighter-weight version of the editor found in our Web IDE. This adds basic code completion and linting for some languages. We’ve also improved source code language detection for better syntax highlighting, and added support for all our syntax highlighting themes. These improvements make it easier to edit and collaborate on files in projects.
Repositories with many contributors combined with highly parallelized CI pipelines, or highly variable project access patterns can cause high CPU and memory usage, decreasing availability. Mitigating these performance problems by sharding generally results in over-provisioning to handle peak load.
Gitaly Cluster allows Git repositories to be replicated on multiple warm Gitaly nodes, and can be used to scale performance by distributing read operations between up-to-date replicas. From GitLab 13.3, when using Gitaly Cluster, read operations will automatically be distributed between up-to-date replicas. This better utilizes the available CPU and memory resources, and scales better in comparison to sharding. Read the Cluster or Shard documentation to learn more about the benefits of Gitaly Cluster.
Note: Gitaly Clusters can be created using GitLab Core and higher tiers. However, technical support is limited to GitLab Premium and Ultimate customers only.
Squashing commits in Git is a great way to combine several commits into a single one. It’s great for grouping several commits, which by themselves may provide little historical value, into a single large commit before pushing upstream. Pushing a single commit allows for a more meaningful commit message, as well as ensuring the group of commits provides a “green” continuous integration pipeline.
In GitLab 13.3 we are adding configurable defaults for squashing commits, allowing project maintainers to configure the option to suit their preferred workflow. Because changing squash configuration may introduce unwanted behavior, configuration has not been changed for new or existing projects. With 314 upvotes 👍, this is one of the most highly requested improvements by the community and we hope it allows more users to use this powerful feature.
WIP (work in progress) status for merge requests provide a clear signal to reviewers
that the merge request in question is not yet ready to be merged.
In order to use a more inclusive and self-explanatory term,
the WIP (work in progress) feature for Merge Requests has been renamed to “Draft”.
This term clearly communicates the MR in question is not ready for
review as well as not making any assumptions about the progress being made towards it.
Additionally, it reduces the cognitive load for new users, non-English speakers, and anyone
not familiar with the WIP acronym.
WIP merge requests are now deprecated in favor of draft merge requests, however both
terms will be supported until the next major GitLab release (14.0), after which it will be
removed.
When reviewing your CI definitions, you can now use our CI linter to go deeper into pipeline processing to validate the correctness of your .gitlab-ci.yml. The CI linter provides feedback not only for syntax validation, but it also validates other kinds of logical errors and invalid configurations by simulating the pipeline as if you were running on master (without actually running anything). This helps you produce a properly configured pipeline faster and helps you avoid situations where a pipeline passed the linter but still could not run.
If you use the rules keyword with if clauses, it’s now even more powerful, with support for bracketed expressions evaluated by the pipeline processor. You can use more complex and efficient AND (&&) / OR (||) expressions, making your pipelines rules more logical, powerful, and easier to manage.
We’re also releasing GitLab Runner 13.3 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.
We introduced the JUnit report in GitLab 12.5 which provides a view of all JUnit tests that run in a pipeline. The wider community helped identify some readability and usability issues in the report interface that made it hard to use, especially when the names of tests or suites exceeded a specific number of characters. Additionally, performance of the page could be slow when parsing very large files or a large quantity of junit.xml files.
Now, you’re presented with a JUnit report that’s easier to read and you can take confidence in the fact that the pipeline page will load quickly even when loading thousands of tests. This feature is no longer behind a feature flag by default and is enabled for all users on GitLab.com.
The GitLab Package Registry is where you store and share a variety of package formats. When you navigate to the user interface, you want to quickly understand how the package was built and how to install it. We’ve redesigned the package details page to prioritize recent activity, code snippets, and additional metadata. We removed the two-column table that had data that was duplicated or not useful.
The main section of the package detail UI now includes:
A new “History” feed that shares the time-based metadata related to a package.
The installation commands and registry setup instructions.
A way to add “Additional Metadata” to capture any metadata not related to time. This additional metadata section offers the flexibility of including a variety of details specific to different package formats.
This change is a clear sign that the Package Registry capabilities with GitLab are maturing. The ‘ugly’ table that we removed was a carry-over from the original Maven Repository. Back then, we only presented basic metadata like name and created_date. Now you can see how a package was built and trace back to which pipeline and which commit was responsible. We look forward to the continued evolution of this product. Enjoy and let us know what you think!
It is too easy to accidentally regenerate an instance ID for a
feature flag when you actually intend to copy the instance ID. If the instance id gets regenerated,
you need to update it in your application and then restart the application in all environments.
Now there is a confirmation step that requires you to type the name of the project before regenerating the ID. This will greatly reduce the risk of unintentional ID regeneration.
Until now, you weren’t able to see Review App links on a Merge Request if you weren’t a member of the respective project where the MR was originally created. In 13.3, we have made review apps accessible to any user, allowing you to get feedback on your code changes from anyone, even your customers. By allowing everyone to contribute, you can better collaborate and shorten your feedback loop.
When an incident occurs, knowing how to respond can be difficult if the on-call engineers didn’t write the code causing an incident. Having access to runbooks, or knowledge about a metric causing alerts, is critical to identifying the root cause of a problem and solving it quickly. You can now add runbooks to the alerts you configure in GitLab so that triggered alerts provide your on-call team the steps needed to resolve the issue.
When triaging alerts, there’s no time to lose: you must investigate quickly without context-switching. GitLab 13.3 saves you time by linking from the chart, located in the Metrics tab of an alert, to the logs for a metric.
When coordinating response teams across multiple incidents, it’s extremely important to know which Incidents are open - and require immediate attention - and which ones are resolved and closed. GitLab 13.3 now separates Incidents by status and organizes them into tabs, helping you to focus on the relevant, open Incidents.
The Project Security Dashboard is getting even more useful with the addition
of new data fields to the vulnerability list. Putting more details on the
main dashboard provides an even better overview of a project’s vulnerabilities
without having to open the individual vulnerability pages.
For scanners that run against source code, you can now see the line number
in the vulnerable file. We’re also including the scanner type (SAST, DAST,
etc.) which you can filter by. This makes it easy to quickly drill into a
specific subset of vulnerabilities.
We’ve also improved the display of vulnerability identifiers. Many scanners
can include more than one identifier for a given vulnerability such as a CVE,
CWE, or a proprietary ID. Previously, we picked the first identifier provided
to display on the vulnerability list. Now, we always show the CVE if one is
available. We also indicate the total number of other identifiers.
We’re enhancing the Vulnerability Management workflow by enabling users to link
existing issues to vulnerabilities. Previously, you could only
associate a single issue with a vulnerability by creating a new issue from
the vulnerability record. These issues were automatically created in the
same project as the vulnerability record.
With this new functionality, you can link one or more existing issues to
a vulnerability. It is also possible to link issues from other projects.
This provides security and development teams greater flexibility and
visibility when managing vulnerabilities, especially across projects.
Geo replicates data from a primary Geo node to one or several Geo
secondary nodes. Backfilling data to secondary nodes as quickly as possible is critical to ensure that secondary nodes don’t fall too far behind.
After a number of iterations (51 MRs!), Geo no longer requires PostgreSQL Foreign Data Wrappers (FDW). This eliminates the possibility of some database timeouts and increases the overall performance of backfill operations. Additionally, this change reduces a step when configuring Geo and makes it easier to maintain a Geo deployment. To give an idea of the reduction in complexity, this change resulted in 3,823 net lines of code being removed.
To prevent PostgreSQL upgrade failures due to insufficient space, and to make the upgrade experience smoother, GitLab now checks to make sure you have sufficient free space before performing a PostgreSQL upgrade with the pg-upgrade command.
It is now easier to specify a timeout value for PostgreSQL upgrades. Previously, the timeout value for pg-upgrade could only be specified in units of milliseconds. It is now also possible to specify the value in days, hours, minutes, seconds, or milliseconds, or some combination of these. For example, 1d2h3m4s5ms.
GitLab 13.3 includes Mattermost 5.25, an open source Slack-alternative whose newest release includes a Jitsi integration for video conferencing and screen sharing, an enhanced Welcomebot plugin, and more. This version also includes security updates. Upgrading from earlier versions is recommended.
One of the benefits of GitLab being a single application for DevOps, is that it is really easy to link content together. We support referencing
labels, milestones, snippets, commits, merge requests, issues, and epics in all parts of GitLab. It is not uncommon for a single piece of content to reference tens or even hundreds of other items. This connectedness however can cause delays in rendering the content to users, as the GitLab server needs to look up each reference to present additional context.
In GitLab 13.3, the performance of reference lookups has been improved significantly. For a sample piece of content with 165 references, it was generated 75% faster with half the memory footprint, resulting in a significantly faster user experience with less load on the GitLab server.
The current code analyzer for the Elasticsearch integration doesn’t take all code cases into account. For example, if you have a file with a.b.c=one_two_three and you search for one_two_three, you wouldn’t get the file returned in the search.
In GitLab 13.3, we have improved the code analyzer in Elasticsearch, and it is now more robust at matching searches with special characters.
Debian Jessie and Raspbian Stretch to be deprecated
Debian Jessie and Raspbian Stretch hit end of life in June 2020. GitLab 13.3
is the last supported version for these distributions. Please visit the
Deprecated OSes
page for more information.
Currently, GitLab supports text/json/logstash log formatting for app logs and text/json/combined for access logs. We will deprecate both logstash and combined, unifying the formatters for both app and access logs with only two options, text (for development) and json.
The Container Registry supports logging hooks, which currently can only be used for email notifications.
These days, alerts based on log entries are commonly handled by separate tools. As far as we know, none of our users rely on this functionality and it is not used at GitLab either. The implementation of this feature is tightly coupled with the underlying logging library, which is a limitation for our ability to switch dependencies without affecting the available features.
In an effort to simplify the registry features and configurations, we will drop support for logging hooks.
Deprecate Container Registry maxidle and maxactive Redis pool settings
Some of the configuration settings that we currently expose for the Redis connection pool are tied to the underlying Redis client and do not have an equivalent in alternative libraries. As we start working on improving the Redis integration, such as adding support for Sentinel, we decided to start working towards replacing the current Redis client dependency with a more feature-rich and better-supported alternative. To do this we need to replace the current Redis pool configuration settings that are tied to the current client library.
We intend to remove the redis.pool.maxidle and redis.pool.maxactive settings and add redis.pool.size (maximum number of connections), redis.pool.miniddle (minimum number of idle connections), and redis.pool.maxlifetime (maximum amount of time a connection may be reused).
Bugsnag is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for Bugsnag.
NewRelic is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for NewRelic.
Deprecation of SAST_EXCLUDED_PATHS in Secret Detection Template
To keep our managed CI templates consistent and streamlined, we are renaming the SAST_EXCLUDED_PATHS variable in the Secret Detection CI template to SECRET_DETECTION_EXCLUDED_PATHS. This will consistently name all Secret Detection CI template variables to start with SECRET_DETECTION_. Please note that SAST_EXCLUDED_PATHS is still a valid variable in the SAST CI template. This change only impacts the Secret Detection CI Template.
To transition, if you use a customized Secret Detection CI template, update the name of the variable in your template. If you use Auto DevOps or inherit GitLab’s managed Secure templates, no action is required.
Since GitLab 13.2, Geo does not require Foreign Data Wrappers (FDW) to be configured for data replication. As a result, the following configuration settings in /etc/gitlab/gitlab.rb are deprecated and will be removed in 14.0:
WIP (work in progress) merge requests term deprecated
We renamed the WIP (work in progress) term for merge requests to “draft”,
because it’s more inclusive and self-explanatory.
The WIP term is now deprecated. We will support its use through the next major
GitLab release (14.0), after which it will be removed.
Since GitLab 13.2, Geo does not require Foreign Data Wrappers (FDW) to be configured for data replication. As a result, the rake task geo:db:refresh_foreign_tables is no longer needed and has been removed in this version.
Removal of SAST Secret Detection job in favor of new template
Since GitLab 13.1, the Secret Detection CI/CD configuration settings are now provided in a separate GitLab-provided template and run as a new Secure scan type. This new Secret Detection template is also now included in Auto DevOps for easy setup.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback