GitLab is enabling IT and business teams to adapt, respond, and thrive. Iteration is the key. To do so you must collaborate rapidly, optimize for efficiency, and automate processes to handle security and compliance while you focus on delivering business value. GitLab 13.0 can help you iterate quickly and with greater insight. At the same time, access to Git repositories is critical, and we have enhanced our Gitaly cluster for high availability Git storage to ensure there are always multiple warm replicas ready to take over if an outage occurs.
Rapidly collaborate and respond across the entire team
Designers are an important part of the development team. While working on one of the most popular new features, the dark themed web IDE, we learned how to pull designers in to collaborate more closely. At the same time, we moved Design Management to core recognizing users who are designing products as individual contributors.
Trust your processes and don’t sacrifice security or compliance
GitLab helps businesses embrace security and compliance controls end-to-end in the software development lifecycle, reducing risk and freeing up resources to focus on business critical needs. Our Application Security Testing capabilities help you find and fix security vulnerabilities earlier and for these, GitLab was just named as a Niche Player in the 2020 Gartner Magic Quadrant for Application Security Testing. Since Gartner's evaluation of 12.4, we have added many new features. In 13.0 alone we've added the ability to scan REST APIs via DAST and a full commit history scan for secrets for even greater detection. More importantly, we have rearchitected the way we handle vulnerability objects. This enabled the ability to export vulnerabilities from the security dashboard and will unlock many more robust Vulnerability Management capabilities in the future.
This month's Most Valuable Person (MVP) is awarded to
Sashi
Sashi contributed a wide variety of improvements across several areas of GitLab during 13.0. Sashi’s work helped improve Versioned Snippets, remove errors related to the Releases tag, minimize duplicate events sent by webhooks. Sashi also improved the organization and readability of the code by ensuring that each package format has unique models for storing metadata.
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.
Internally, Git repository storage is handled by Gitaly, and now Praefect too. Praefect is a new router and transaction manager we built for Gitaly to coordinate leader election and asynchronous replication. When using a Gitaly Cluster, requests for Git data are routed through one of multiple Praefect nodes to a Gitaly node. This means that there are always multiple warm replicas ready to take over if an outage occurs.
In the future we plan to support strong consistency, so that write operations succeed on multiple Gitaly nodes, before responding with a success signal, and support horizontally distributing reads so that CPU and memory resources can be better scaled.
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. Auto DevOps simplifies and accelerates delivery and cloud deployment with a complete delivery pipeline out of the box. Simply commit code and GitLab does the rest! With the elimination of the complexities, teams can focus on the innovative aspects of software creation!
In order to enable this workflow, users need to define AWS typed environment variables: AWS_ACCESS_KEY_ID, AWS_ACCOUNT_ID and AWS_REGION, and enable Auto DevOps. Then, your ECS deployment will be automatically built for you with a complete, automatic, delivery pipeline.
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!
Snippets are useful for sharing small bits of code and text that may not belong in the main project’s codebase. These items are important to groups and users who rely on them for other tasks, like scripts to help generate diagnostic output or setup supporting services for testing and demo environments. Unfortunately, a lack of version control has made it hard to know if a snippet was the latest version or what changes may have happened and how to reconcile those.
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.
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 for other editors and important for providing a comfortable experience. It’s also clear that GitLab users love their dark themes as a Dark Application theme for all of GitLab is the second most popular request in the GitLab Issue Tracker.
The GitLab Web IDE is now completely themed dark for users who choose the Darksyntax highlighting theme perference. This is an important step in delivering an editing experience users love and a valuable step in understanding how the GitLab UI responds to dark themes. You can read more about the design process here.
We are excited to announce the first feature release for Vulnerability
Management, standalone vulnerability objects. With this release, we’ve
implemented a new vulnerability object model, enabling a whole new set
of capabilities that span the entire lifecycle of vulnerability
management.
One of the biggest benefits is each vulnerability occurrence will now
have a unique URL, meaning a vulnerability can be directly linked to,
shared, referenced, and tracked as the Single Source of Truth. On this page, you can change the status of a vulnerability to Detected, Confirmed, Dismissed, or Resolved. Another
benefit is vulnerability occurrences will persist across scanner runs.
Previously, running scans on the same branch would overwrite any
previous findings with the new results. Persisting vulnerabilities will
improve tracking, visibility, and cut down on duplication of findings
between runs. It also enables the future ability to report on group and
project vulnerability trends over time across a broad range of
variables.
GitLab 13.0 supports DAST scans of REST APIs. This allows for full DAST security coverage of an application, not just the UI. By supporting use of an OpenAPI specification as a guide for what URLs and REST endpoints need to be scanned, DAST helps secure an application’s entire attack surface and provides more insight into the potential vulnerabilities of any running application.
We’re introducing initial support for .Net Framework which will allow developers to enable SAST Security Scans on additional types of .NET projects. Like our other SAST jobs, this will use Linux GitLab Runners. We plan to expand support to GitLab Windows Runners in a future release. Since introduction in GitLab 11.0, SAST for .NET only contained support for .NET Core projects.
If you use Terraform to define your infrastructure as code, you know the pain of having to pass around the resulting changes from your terraform plan command in slack and MR comments. In GitLab 13.0, you can now see the summary of your terraform plan command in the context where it is most useful, directly in your merge request. This helps you to more quickly verify your infrastructure changes and gives you a place to collaborate with your team members on the intended effects of your infrastructure as code changes.
Users of Terraform know the pain of setting up their state file (a map of your configuration to real-world resources that also keeps track of additional metadata). The process includes starting a new Terraform project and setting up a third party backend to store the state file that is reliable, secure, and outside of your git repo.
Many users wanted a simpler way to set up their state file storage without involving additional services or setups. Starting with GitLab 13.0, GitLab can be used as an HTTP backend for Terraform, eliminating the need to set up state storage separately for every new project.
The GitLab HTTP Terraform state backend allows for a seamless experience with minimal configuration, and the ability to store your state files in a location controlled by the GitLab instance. They can be accessed using Terraform’s HTTP backend, leveraging GitLab for authentication. Users can migrate to the GitLab HTTP Terraform backend easily, while also accessing it from their local terminals.
The GitLab HTTP Terraform state backend supports:
Multiple named state files per project
Locking
Object storage
Encryption at rest
It is available both for GitLab Self-Managed installations and on GitLab.com.
Storing large binary files in Git is normally discouraged, because every large file added will be downloaded by everyone who clones or fetches changes thereafter. This is slow, if not a complete obstruction when working from a slow or unreliable internet connection.
In GitLab 13.0, Partial Clone has been enabled for blob size filters, as well as experimentally for other filters. This allows troublesome large files to be excluded from clones and fetches. When Git encounters a missing file, it will be downloaded on demand. When cloning a project, use the --filter=blob:none or --filter=blob:limit=1m to exclude blobs completely or by file size. Note, Partial Clone requires at least Git 2.22.0.
Read more in our recent blog, How Git Partial Clone lets you fetch only the large file you need.
In GitLab 13.0, you can create dashboards powered by variables, enabling you to use a single dashboard to monitor multiple services and components, rather than creating hard-coded dashboards for each service you want to monitor. Instead of the time-consuming and repetitive task of recreating similar dashboards multiple times, you can now create a single dashboard and use variables to change the data you view in it.
Puma is now the default web application server for both the Omnibus-based and Helm-based installations. Puma reduces the memory footprint of GitLab by about 40% compared to Unicorn, increasing the efficiency of GitLab and potentially saving costs for self-managed instances.
Installations which have customized the number of Unicorn processes, or use a slower NFS drive, may have to adjust the default Puma configuration. See the Important notes on upgrading and GitLab chart improvements for additional details.
Auditability and traceability are critical components of an organization’s compliance program. Previously, actions taken by an administrator, who impersonated another user, would be captured in the audit events table as if the impersonated user was taking those actions. Now, audit events will show you when specific actions were the result of an administrator’s impersonation activity.
This important addition to audit events corrects a gap in nonrepudiation for your compliance program and adds to the reliability and comprehensiveness of your GitLab audit events data.
Previously, the translation of instance-level default branch protection settings down into projects was confusing because, in certain scenarios, it created an unintuitive experience: developers could not push new commits to projects they could create. This made it difficult for organizations to strike a balance between mitigating risk and allowing carte blanche access to projects for all developers since the workaround required promoting them to Maintainer.
Now, default branch protection can be set at the group level to provide better flexibility for administrators and group owners. Using a combination of default branch protection and default project creation settings, organizations can find the right mix of autonomy and control, such as using custom default branch protection and allowing only maintainers to create new projects. This would allow developers to push new commits (not force push or delete a branch) to new projects, but allow maintainers to control project creation.
This group-level configuration of default branch protection can be disabled for organizations requiring more strict controls in place. By disabling the group-level setting for default branch protection, maintainers can apply more stringent controls on developer access and permissions.
When you need to find a specific event, either for audit reporting or to investigate incidents, it should be easy. It shouldn’t require a lot of time to manually dig through a large data set.
Now, you can perform filtered searches on a single object, e.g., a user, group, or project in the instance-level audit events table to make this process much easier. This feature is available for self-managed customers only, but will be extended to groups and projects as part of a the larger epic to make the instance, group, and project-level audit events experiences uniform and much friendlier to use.
We now offer an Okta SCIM integration application for Gitlab.com groups! When Okta SCIM is provisioned for a GitLab group, membership of that group is synchronized between GitLab and Okta.
This reduces group administrator time spent to onboard and offboard users.
This powerful new chart allows teams to see how delivery is distributed across different types of work. Use labels to see how many features are delivered vs. bugs from release to release, or how many items a given team ships vs. another. By reflecting on the distribution of work delivered through the value stream, teams can tune their processes to better align with strategic objectives or better balance resources across teams.
Often when organizing or curating an epic, you need to move an existing issue to another epic in the tree.
You can now move an issue to a different epic via drag and drop, instead of having to click through multiple tabs.
Accurately tracking the status of work in flight is a must to help keep teams on track. Now, when viewing your
roadmap, you can view how your epics line up with your various milestones helping you better understand
when work will land, and identify if projects are ahead or behind expectations.
Easily navigating commits in large merge requests allows reviewers to be more efficient
while reviewing on a commit-per-commit basis.
The new commit navigation buttons allows users to seamlessly navigate between the current
commit to the previous or next commit, making it more efficient to review merge request
with a large number of changes.
With the release of Versioned Snippets in GitLab 13.0, we’ve upgraded the Snippets editor to a lighter-weight version of the editor found in our Web IDE. With this editor, users will benefit from 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 will make it easier to edit and collaborate on Snippets.
We’re excited to bring consistency to the editors in Snippets and the Web IDE. In a future release we’ll expand this functionality to our single file editor and in our .gitlab-ci.yml editing experiences.
Groups can be used for organizing users in GitLab. This makes it easy to share projects,
mention in comments, or assign as merge request approvers without selecting them one at a time.
Groups and users can be assigned as code owners, but ancestor groups could not be used.
This meant assigning a parent group from the project hierarchy as a code owner had no effect.
GitLab 13.0 introduces the ability to include users and groups from a parent or ancestor group in a
project’s CODEOWNERS file, providing more flexibility when specifying Code Owners’
rules.
In 13.0, Design discussions are one step closer to the commenting experience in GitLab. We’ve added emoji support so you can convey your feedback in a more fun and imaginative way! 😼
Markdown is a powerful and efficient syntax for authoring web content, but even seasoned authors of Markdown content can struggle to remember some of the less-frequently used formatting options or write even moderately-complex tables from scratch. There are some jobs better accomplished with a rich text, “What You See Is What You Get” (WYSIWYG) editor.
GitLab 13.0 brings a WYSIWYG Markdown authoring experience to the Static Site Editor with formatting options for common formatting options like headers, bold, italics, links, lists, blockquotes, and code blocks. The WYSIWYG editor also removes the onerous task of editing tables in Markdown by letting you visually edit table rows, columns and cells in the same way you would edit a spreadsheet. For those more comfortable writing in raw Markdown, there’s even a tab for switching between WYSIWYG and plain text editing modes.
Searching for pipelines triggered by a specific user or that ran on a particular branch is now easier than ever before. With a new filter feature on the pipelines page, it is now possible to filter by trigger author and/or by branch name. Being able to refine the pipelines view by applying these filters will help to stay informed of pipeline activities that matter most to you.
Passing environment variables (or other data) between CI jobs is now possible. By using the dependencies keyword (or needs keyword for DAG pipelines), a job can inherit variables from other jobs if they are sourced with dotenv report artifacts. This offers a more graceful approach for updating variables between jobs compared to artifacts or passing files.
GitLab Runner 13.0 now supports downloading artifacts directly from object storage. When this option is enabled the GitLab server will redirect
the Runner directly to object storage, rather than proxying the traffic. This can result in significant cost savings on network transfer costs, as well as
reduced load on the GitLab server.
To enable set the FF_USE_DIRECT_DOWNLOAD feature flag to true
via an environment variable.
The GitLab Package Registry has been treating each new version of a package as a new package. This has made it difficult to find the package you are looking for or to understand what has changed from version to version.
In GitLab 13.0, we are excited to announce that each version of a package will now be nested under its uniquely-named parent. This will make it easier to find the package you are looking for in the UI and to better understand what has changed from version to version. This change applies to both the group and project-level views of the Package Registry. In addition, when using the Packages API, versions will now be returned as an array within the parent package.
When you or someone on your team publishes an image to the GitLab Container Registry, you need a way to quickly find it and ensure the image was built properly. If you’re using GitLab CI/CD to publish images with each build, it’s been very difficult to find an image efficiently within the current user interface. Instead, you’ve relied on the command line or the API.
We are excited to announce that in 13.0, we’ve added search functionality to the GitLab Container Registry. Simply navigate to your project or group’s registry and enter an image name to see a list of all your images.
Before this release, the Package Registry list view showed a limited amount of information related to the packages in the UI. While this information is important, it lacked key metadata such as version, branch, and commit.
In 13.0, we’ve updated the design of this page to include additional metadata to help you find the package you are looking for and verify it was built properly. In addition to the package name, you can now see version, type, and more. Check out the video for an example or start using the feature today.
We know that understanding what GitLab scans for is important to ensure
that you feel safe. With this release, we are introducing a new page
to give you more information about the vulnerability database our
scanners use.
From this page, you can get information about what we are scanning for,
when we last updated our database, and also look up specific
vulnerabilities you are concerned about.
DAST analyzes your running web application for known runtime vulnerabilities, starting with each merge request. DAST scans many resources, but knowing precisely which ones was not possible before.
GitLab 13.0 presents a full list of the resources that DAST scanned. You can now evaluate DAST scans to ensure all necessary application surfaces are covered. For further ease of analysis, you can download scan lists directly from the results screen.
In GitLab 13.0, you can now add your frequently-used dashboards to your favorites by clicking the Star button. Starring a dashboard displays it first in the dashboard search bar results to save you time.
When an incident response team shares incident updates and status changes, the incident description is published publicly, but all user and group names in issue descriptions are anonymized to protect the privacy of individuals and teams.
The alert list view is helpful for triaging problems at a high-level, but it does not provide enough space for all alert attributes and the payload. The new alert detail page is dedicated to displaying and organizing the alert payload and annotations so that responders can quickly find critical information during an investigation.
As GitLab grows, Geo continues to support replication for additional
resources. This in turn increases the number of status pages that are
shown in the sidebar. This approach does not scale well and makes it
harder for systems administrators to find what they need. In GitLab
13.0, we merged the sub-pages for Projects, Uploads and Designs into a
single view that
can be accessed via a single sidebar entry “Replication”. This change
groups all the information in one place and helps systems administrators
access the replication status of individual items.
Additionally, we’ve made a few other user experience improvements to the
administrator interface:
The Helm chart now supports configuration of multiple Redis instances. This allows you to have different Redis instances for different storage types, for use with our 10,000 users Reference Architecture. For details on specific changes, refer to the issue.
Now that Puma is the default web application server, with the option to still switch back to using Unicorn, the name of the Unicorn chart has changed from unicorn to webservice. For configuration details, see the Charts documentation.
The ConfigMap entries for puma.rb and unicorn.rb files have been removed in favor of environment variables. Please note that if you have modified the unicorn.rb from the ConfigMap (via Helm + Kustomize) in the past, you will be impacted by this change. We are doing this to eliminate maintaining two copies of these files. Until now, the puma.rb and unicorn.rb files were static within the gitlab-webservice container and overwritten by ConfigMap items from the gitlab/unicorn chart. For details on the new environment variables, refer to the associated merge request.
The version of Ruby used by the GitLab Helm chart has been updated to 2.6.6.
Improved Geo replication performance for Job Artifacts, Uploads and LFS files
These iterations bring us closer to removing Geo’s dependency on
Foreign Data
Wrappers, which
were added for improved performance, but makes Geo more complex and
harder to maintain.
We are continuing to make great strides improving the performance of GitLab in every release. We’re committed to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!
In GitLab 13.0 we are shipping performance improvements for issues, projects, milestones, and a lot more! Some of the improvements in GitLab 13.0 are:
GitLab’s Release Management team is working on expanding the Release Page to include all the Release API’s functionality. In 13.0, it is now easier to add a single or multiple milestones to your Releases. With this addition, you no longer have to manually call the Release API to take advantage of planning features, such as the Release Progress View, which was introduced in 12.9.
We’re pleased to announce a new SIEM integration for the Web Application Firewall (WAF)!
The integration allows users to export their WAF logs to a SIEM or central logging solution
so they can review any anomalies detected by their WAF. This visibility into the logs also
helps users to test and tune their WAF rules to reduce false positive rates. The SIEM
integration can be configured by enabling Fluentd on the Operations -> Kubernetes page.
Users will now receive an email notification when a sign-in using their credentials occurs from a new IP address or device. This new functionality helps users quickly identify potential malicious activity related to their accounts.
Previously, users could only migrate groups by using the Export/Import API to create an Export file, then using the API a second time to upload the file to the target instance.
As a first step toward a more frictionless solution, we have enabled Group Export in the GitLab UI. We plan to introduce similar Import functionality to the UI within the next few weeks.
Push rules provide additional control over what can and can’t be pushed to your repository. They allow you to create custom operational standards that align with your organizational policies.
Previously, push rules could only be set at the instance or project level, forcing admins to manage large numbers of people and projects independently. New group-level push rules will allow group owners a way to govern policy in a central location, while still providing individual project owners with flexibility.
Two key value stream metrics now give teams a baseline against which process improvement efforts may be measured so that they may more easily see the impact of process changes. Lead time measures the elasped time between a requested item and its delivery. Cycle time measures the length of the development cycle itself. By optimizing flow across the entire value stream, teams avoid moving a problem from one place to another and ship faster.
Creating and adding issues and epics in the Epic tree used to be split across multiple buttons and drop down menus,
and was somewhat cumbersome to use. We have consolidated the “add” and “create” actions into a single button and menu to make it
easier and faster to add new issues and epics!
In GitLab 12.8, we introduced the ability to create dependencies between issues, where one issue can block another related issue. This means that the downstream issue should not be closed until the predecessor is completed and closed. This required you to check to see if an issue is blocked before you closed it.
Having to check if an issue is blocked prior to closing the issue is an
additional step that is unnecessary and easy to forget.
We’ve eliminated that step by showing you a warning if you attempt to
close an issue with unresolved blockers. We also provide links
to the blocking issues so you can verify that your issue is safe to
close.
This level of increased dependency alerts helps keep projects running
smoothly, and ensures that sequencing of issues can be maintained!
Merge Request Approvals require specific people to approve changes before they can be merged.
When searching the merge request list, you can quickly find which merge requests need your
approval using the Approvers filter. In GitLab 13.0, you can now also find any merge requests
you previously approved using the new Approved-By filter.
In the 12.2 release, Design Management debuted with Design Uploads and Point of Interest Discussions as a GitLab Premium feature. Since then, we’ve considered our users who are designing products as individual contributors and, in 13.0, we’re excited to announce we’ve moved these two features down to GitLab Core! This aligns with our Individual Contributor Buying Model and we expect to add other great team features in the future, like approvals, as we progress towards category maturity.
So now, all users can upload and participate in design feedback on issues in GitLab!
As a refresher, you’ll find the Design tab next to the Discussion tab on any issue. Try a drag-and-drop upload of a screenshot to get started!
Merge Requests, particularly the Changes tab, is where source code
is reviewed and discussed. In circumstances where the target branch was
merged into the source branch of the merge request, the changes in the
source and target branch can be shown mixed together making it hard to
understand which changes are being added and which already exist in the
target branch.
In GitLab 13.0, we are adding an experimental comparison mode, which
will show a diff calculated by simulating a merge - a more accurate
representation of the change than using the merge base of the two
branches. The new mode is available from the comparison target drop down
by selecting master (HEAD). In the future it will
replace the
current default comparison.
GitLab supports six syntax highlighting preferences when viewing code. Themes are important to developers when viewing and editing code on GitLab since it’s imperative that they work comfortably throughout the day. We’ve now released support for all six syntax highlighting preferences in the Web IDE. This includes Solarized Dark, Solarized Light, Monokai and a no highlighting option.
Over the last few releases (for example, 12.8 and 12.9) we’ve been steadily adding and improving support for syntax highlighting preferences in the Web IDE. These updates follow this effort and help to lay the foundation for our Dark Theme in the Web IDE, also launching in 13.0. We’re excited to continue to expand on developer experience and making the Web IDE feel more like home.
When there are a lot of discussion threads on a design it can be hard to identify which thread relates to which comment pin on the design without scanning for the correct comment number.
In 13.0, we added a mechanism to highlight the relevant design discussion comment pin when you click on the comment. We also added the reverse where you can click on the comment pin and have the relevent comment scroll into view. This reduces manual scrolling and sifting through the noise when you have lots of comment pins.
Browser Performance Testing allows users to easily detect when there is a degradation in their web app before merging to master. In many cases this causes extra noise and clutters up the Merge Request page unnecessarily, even for minor changes.
In this milestone, you can now set an optional degradation threshold as a requirement that must be met before the Performance report will be displayed.
We’re also releasing GitLab Runner 13.0 today! GitLab Runner is the lightweight, highly scalable, cross-platform software agent 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.
A JUnit report can contain a wealth of information that can be used to update test plans, test execution history, and other artifacts which teams use to track the quality of their code. Updating those artifacts can be a painful, manual, process made worse by the fact that JUnit reports are only available to download from the GitLab UI.
Starting in GitLab 13.0 users of the GitLab API will be able to access JUnit reports directly. This will enable users to parse JUnit data to create new issues or update test execution history.
When using GitLab’s Image Expiration Policy, there is no way to express something such as “no matter what, don’t delete this tag”. This introduces risk into the deletion process, as it’s possible to delete release or master images, which should be immutable.
In 13.0 we are excited to announce that you can now update your project’s expiration policy to identify images you never want deleted. Simply enable the policy and use regex to identify the image you want to preserve.
Deploy Tokens allow you to access your group’s repositories, project’s repositories, and container registries. Historically, the defined scopes of read_repository, read_registry, and write_registry have not allowed you to grant access to the GitLab Package Registry. As a result, DevOps teams have used insecure or expensive user-based workarounds.
In GitLab 13.0, we are excited to announce more granular permissions for GitLab Deploy Tokens. You can now set read or write access for the Package Registry. You can also create and manage Deploy Tokens from within the GitLab application or by using the API.
The GitLab Package Registry user interface allows you to confirm that your packages have been built properly and troubleshoot when something has gone wrong. However, the MVC of the new PyPI Repository that launched in 12.10 did not include this functionality.
In 13.0, we’ve added the PyPI Repository to the Package Registry UI. Now, you can view and download your project or group’s PyPI packages and reference metadata to validate that the package was built properly. You can also quickly copy setup and install commands for more efficient sharing and coding. If the package was built using a GitLab pipeline, you’ll be able to view and link it to the pipeline, as well as the commit that was used to publish the package.
We’re pleased to announce the initial release of exportable vulnerability
lists from the Instance Security Dashboard and Project Security Dashboard.
While the Security Dashboards let users manage vulnerabilities as part of
the GitLab workflow, it hasn’t been as easy to get a list of this information
for external use.
You can now download a CSV file containing the detected vulnerabilities
for a given project or all projects configured on the Instance Security
Dashboard. This export list can then be used for things such as creating
compliance reports or as a data source for external dashboards.
Simply go to the instance Security Dashboard or any project’s Security Dashboard and click the new Export
button in the upper-right or go to the Security option under the More menu
in the top navigation bar, then click the new Export button in the
upper-right. Your browser will automatically start the download.
GitLab 13.0 updates our Secret Detection Security Scanning to support a new configuration variable (SAST_GITLEAKS_HISTORIC_SCAN) to allow scanning the full history of a repository. This allows you to identify historical secrets that might be hiding in your older git commit history. Since introduction in GitLab 11.9, Secret Detection scanned the commit history of changes in a merge request. This would detect new secrets but would not identify secrets in the repository’s older git history. This new functionality is particularly useful when you are enabling Secret Detection in a repository for the first time and you want to perform a full secret scan.
Sometimes your metric charts can be hard to understand. Starting in GitLab 13.0, you can now add annotations to your metrics charts which appear as dotted horizontal lines overlaid on your graphs and charts, to help you interpret and understand the data.
When responding to alerts, responders need a single interface that aggregates IT alerts originating from multiple sources. The new alerts list enables you to sort through alerts quickly and intuitively to help you find and triage the most critical problems first. You can access the alerts list at Operations » Alerts.
GitLab issues support emojis in the issue title and all Markdown fields. When you publish a Gitlab issue to a public URL as a status page, the status page now supports and renders emojis used in issue titles, descriptions, and comments.
Previously, project administrators couldn’t control permission to view a project’s metrics dashboards. As part of GitLab 13.0, admins can now toggle metric dashboard visibility to either project members, or to everyone with access.
As part of our support for Feature Flag lists, we have added API support to enable creating, editing, and deleting them. This will make it easier to automate the management and synchronization of these lists between different systems.
We’re pleased to announce a new SIEM integration for Container Network Policies!
The integration allows users to export their Cilium logs to a SIEM or central logging solution
so they can review any anomalies detected by their Network Policies. This visibility into the logs also
helps users to test and tune their Network Policies to reduce false positive rates. The SIEM
integration can be configured on the Operations > Kubernetes page.
Geo supports selective
synchronization
of projects, which allows systems administrators to choose a subset of
data that is replicated to a secondary Geo node. Geo already supports
redirecting HTTP(S) requests to the primary when trying to access these
unsynchronized repositories. However, users trying to access
unsynchronized repositories on a secondary node via SSH would receive an
error that the repository was not available. This was confusing for
users and forced them to either wait for the repository to synchronize
or do extra work to connect to the right repository.
In GitLab 13.0, any Git requests made via SSH to an unsynchronized
secondary Geo node will be forwarded to the primary node. This results
in a much more seamless user experience because users won’t need to know
what is or isn’t replicated to this node - Geo will fulfill the request
both via HTTP(S) and SSH without any additional configuration.
In this milestone, GitLab introduces more controls for environments. With the Freeze Period API, you can easily prevent an unintended production release during a period of time specified by you, whether it is a large company event or holiday. You can now rely on the enforcement of policies that are typically outside the scope of GitLab to reduce uncertainty and risk while automating deployments.
In Redis 5, the terminology for slave was changed to replica. In GitLab 13.0, this change was made in the Redis configuration in Omnibus. See Important notes on upgrading for upgrade instructions.
GitLab 13.0 includes Mattermost 5.22, an open source Slack-alternative. This release includes team switch shortcuts, ability to unarchive channels from the user interface, experimental channel sidebar features, and much more. This version also includes security updates. If you have a Mattermost environment that contains a lot of emoji reactions, please refer to Important notes on upgrading for information on longer upgrade times.
The version of Ruby packaged in Omnibus GitLab has been updated to 2.6.6.
The minimal required version of PostgreSQL for all self-managed installations is now PostgreSQL 11. PostgreSQL versions 9.6 and 10 have been removed in GitLab 13.0. This update allows us to start introducing performance improvements based on the partitioning features that were added in PostgreSQL 11. We plan to support PostgreSQL 11 for the entire duration of the GitLab 13.x series of releases. Support for PostgreSQL 12 will be added in the near future. See Important notes on upgrading for PostgreSQL-related upgrade guidelines.
Cloud Native Buildpacks are the next iteration of buildpacks. While GitLab currently defaults to Herokuish buildpacks, we intend to move Auto DevOps to Cloud Native Buildpacks when the project matures, to provide a future-proof and well-maintained solution to our users. With this release, you can opt in to use the beta for Cloud Native Buildpacks in Auto DevOps pipelines by setting the AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED CI variable.
Because several APIs were removed in Kubernetes 1.16, the default value of extensions/v1beta1 for the deploymentApiVersion setting in Auto DevOps’ Auto-Deploy chart is now deprecated in GitLab 13.0.
Auto DevOps and Secure Configuration templates are changing to `rules` instead of `only/except`
The use of only and except is discouraged in favor of rules in Auto DevOps and Secure Configuration templates. The rules parameter provides more verbose and expressive job execution logic that is simpler to evaluate and easier to understand.
Auto DevOps and Secure configuration templates that use only and except will transition to rules, starting in GitLab 13.0. We strongly encourage customers who have customized job templates to transition because the only/except and rules syntax cannot be used together. For help migrating your templates, see Transition your only/except syntax to rules.
This change will affect the following job configuration templates:
Any customization to Auto DevOps and Secure Configuration templates using only and except should be transitioned to the rules syntax. There are occasional cases where the existing only and except syntax cannot be easily matched with rules. We would love to hear more about these cases on this rules improvement issue.
Auto DevOps' default PostgreSQL version is changing
As part of updating Auto DevOps in GitLab 12.9 to support
Kubernetes 1.16, we added the opt-in ability for Auto DevOps to use the
PostgreSQL chart version 8.2.1. The default PostgreSQL chart version in
GitLab 12.10 is currently 0.7.1. GitLab 13.0 switches the default
PostgreSQL chart version from 0.7.1 to 8.2.1. To remain on the old
default version, you must explicitly set the
AUTO_DEVOPS_POSTGRES_CHANNEL CI variable to 1.
To migrate your existing 0.7.1 PostgreSQL database to the newer
8.2.1-based database, follow the
upgrade guide
to backup your database, install the new version of PostgreSQL, and
restore your database.
Deprecation date:
May 22, 2020
Deprecate Windows batch `cmd` for the shell executor
In GitLab 11.11, we announced the deprecation of the Windows batch executor, Cmd shell, for the GitLab Runner in favor of PowerShell. In 13.0, we have deprecated the use of the Windows batch executor for the GitLab Runner. PowerShell is the default command shell when a new Runner is registered that uses the Windows executor starting with GitLab Runner 12.0. The Cmd shell remains included in future versions of GitLab Runner. However, any new Runner feature is to be tested and supported only for use with PowerShell. You can find more details in issue #4163.
Deprecation date:
May 22, 2020
Deprecation of Docker-in-Docker (DinD) for Security Scanners
To increase the security and reduce complexity of scans, use of Docker-in-Docker (DinD) in GitLab Secure scanners has been deprecated. GitLab security products will begin to use non-DinD mode by default in vendored templates in GitLab 13.0. We encourage customers to update their vendored templates to use this new behavior.
If you want to continue using DinD mode instead, see Enabling Docker-in-Docker for Dependency Scanning. In a future release we intend to remove DinD completely. Please be aware of slight changes in scanner detection logic, which we have largely mitigated.
We’re changing how some of the configuration options in GitLab Pages behave to streamline the initial setup, while helping you avoid misconfiguration. If you installed GitLab by using the Omnibus, no action is required. Otherwise, you’ll need to set the gitlab-server parameter and remove auth-server.
Deprecation date:
June 22, 2021
Planned deprecation of variables SAST_ANALYZER_IMAGE_PREFIX and DS_ANALYZER_IMAGE_PREFIX in Secure CI Templates
To help streamline and simplify the setup of GitLab Security Tools, we have introduced a new global variable SECURE_ANALYZERS_PREFIX which by default points at the GitLab registry. This variable replaces the now deprecated variables in SAST and Dependency scanning: SAST_ANALYZER_IMAGE_PREFIX and DS_ANALYZER_IMAGE_PREFIX. Support for these deprecated variables will be removed in a future release, so please migrate any usage to SECURE_ANALYZERS_PREFIX.
You can override this variable to easily affect all security scanners at once. This is useful in situations where you are using your own registry images which is common in offline and air-gapped environments.
GitLab currently supports two types of storage for repositories: Legacy storage and hashed storage. Hashed storage makes the folder structure immutable and results in performance and security improvements.
Hashed storage has been available since GitLab 10.0 and is on by default since GitLab 12.0. GitLab.com has been fully migrated to hashed storage. With GitLab 13.0 legacy storage is deprecated and we are planning to fully remove legacy storage in 14.0.
Administrators will no longer be able to disable hashed storage for new projects.
New projects and renamed projects will use hashed storage by default.
When renaming or moving projects they will be migrated to hashed storage automatically.
In 13.2:
Upon upgrading to 13.2, all projects still in legacy storage will be automatically migrated via a background migration.
Some new features may require hashed storage and won’t be available when using legacy storage.
In 14.0:
Legacy storage support will be completely removed from GitLab. Users must migrate to hashed storage before upgrading to 14.0.
Deprecation date:
May 22, 2020
Prometheus replaces InfluxDB for self-monitoring
Starting in GitLab 13.0, InfluxDB is being deprecated in favor of Prometheus for GitLab self-monitoring metrics. Please update your configuration for GitLab reporting and visualizations to use Prometheus, which is installed by default on every GitLab instance.
Deprecation date:
June 22, 2020
Removal of deprecated project paths
With the introduction of subgroups, GitLab’s URL path structure became more complex. We’ve been introducing a separator, /-/, to improve clarity between groups, projects, and pages within a project. For example, https://gitlab.com/gitlab-org/gitlab/issues is now https://gitlab.com/gitlab-org/gitlab/-/issues. These changes result in improved performance, stability, and simplicity.
As we introduce the separator to additional pages, we automatically redirect requests to the old paths to the new ones. With GitLab 13.0, we are removing this redirect for pages which have had the separator since GitLab 12.0.
Regular usage of GitLab will not be impacted by this change. However bookmarks or scripting created over a year ago, utilizing an affected path, will need to be updated to utilize the new path.
Deprecation date:
Jun 22, 2020
Removal of logs view from the admin dashboard
Logs can no longer be viewed from within GitLab admin dashboard. These logs
used to be read directly from disk to be displayed in the admin
interface. Sadly, this does not work in multi-node setups and
could cause confusion for administrators by displaying partial
information. The logs are still available to administrators with
access to the host, please see the documentation on our log
system
for more information. For multi-node systems we recommend ingesting
the logs into services like Elasticsearch and Splunk.
Deprecation date:
May 22, 2020
SSH `authorized_keys` file deprecated
As of GitLab 13.0, the bin/authorized_keys file used for SSH authorization is deprecated,
replaced by bin/gitlab-shell-authorized-keys-check, which conducts the authorization through
fast lookup instead.
The deprecated method wasn’t reliable as it doesn’t check that the requesting user matches
the expected user. The final removal is scheduled for GitLab 13.1, released next month (June 22nd, 2020).
Deprecation date:
May 22, 2020
The default method of invoking Sidekiq will be `sidekiq-cluster`
As stated in the 12.10 release post, in GitLab 13.0 we have deprecated alternative
ways of starting Sidekiq in favor of Sidekiq Cluster. Sidekiq Cluster provides additional options for managing Sidekiq queues and scaling.
This enables running multiple Sidekiq processes
for Core instances (a previously EE exclusive feature). Multiple Sidekiq processes allow a GitLab instance to continue to scale vertically, and are often a good first step prior to adding additional nodes. In addition, this will allow us to simplify support and improve maintainability for GitLab.com.
Directly invoking Sidekiq will no longer be supported as of 14.0.
For more information on falling back to the old (deprecated) behavior,
please refer to either Omnibus or
Helm charts docs.
Bug reports in this issue will be greatly appreciated.
Deprecation date:
May 22, 2020
Unicorn will be removed in favor of Puma
Unicorn support is deprecated and will be removed in GitLab 14.0. Learn more about migrating to Puma.
Deprecation date:
June 22, 2021
Removals
Auto DevOps' postgres chart upgrading to ver 7.7.3
As Kubernetes 1.16 no longer serves resources on the extensions/* and apps/beta*
API endpoints, all dependent resources are upgraded to consume the new apps/v1 API endpoint.
If you are making use of the postgres database served by Auto DevOps, see the
migration guide
in order to backup your database, upgrade postgres version, and restore your database.
Removal date:
May 22, 2020
GitLab Pages auth_server attribute removed
The auth_server setting (with an underscore [_]) for configuring access control when running GitLab Pages on a separate server was deprecated in a previous release in favor of the gitlab_server setting. This change was made because the data that GitLab Pages gets from GitLab now extends beyond just authentication. The auth_server setting has been removed in 13.0.
Removal date:
May 22, 2020
GitLab Snippets content search removal in 13.0
With the release of Versioned Snippets, files in Snippets are no longer available via search from the UI and API. Title and Description content will be accessible via search and API.
Removal date:
May 22, 2020.
NFS for Git repository storage deprecated
With the general availability of Gitaly Cluster in GitLab 13.0, we are deprecating NFS for Git storage. We
intend to remove support for NFS for Git repositories in GitLab 14.0. We are taking this action early to
communicate our intent clearly, and avoid customers purchasing expensive NFS appliances that are not needed.
We invite customers currently using NFS for Git repositories to begin planning their migration. There are multiple
use cases for NFS for Git storage, and we are working to address these in our
Gitaly Cluster roadmap.
Removal date:
May 22, 2020
PostgreSQL 9.6 and 10 removed no longer supported
The minimal required version of PostgreSQL for all self-managed installations is now PostgreSQL 11. PostgreSQL versions 9.6 and 10 have been from the Omnibus package and Helm charts. The removal of support for 9.6 and 10 allows us to build upon the latest features and performance improvements available in PostgreSQL 11. For more details, see the release post on PostgreSQL 11.
Removal date:
May 22, 2020
Protected path configuration removed from `gitlab.rb`
Configuration settings for protected path rate limits have been removed from gitlab.rb. Configuration of protected paths was moved to the GitLab Admin UI in GitLab 12.4.
Removal date:
May 22, 2020
Redis 3 no longer supported
Redis 3 has reached end of life and is no longer supported starting in GitLab 13.0. The bundled Redis version was updated to Redis 5 in GitLab 12.7 and GitLab Cloud Native Chart 3.0.
Removal date:
May 22, 2020
Release API evidence_sha and evidence_file_path deprecated
Now that users can create Release Evidence on demand, GitLab supports multiple Evidence objects, each of which exposes the summary_sha and filepath fields. Access to the original Evidence object is separately available via the deprecated evidence_sha and evidence_file_path fields in the Releases API. Updates to 13.0 make it possible to continue using Release Evidence and to be able to leverage on demand evidence collection.
Removal date:
May 22, 2020
Release API evidence_sha and evidence_file_path removed
Now that users can create Release Evidence on demand, GitLab supports multiple Evidence objects, each of which exposes the summary_sha and filepath fields. The original Evidence object is accessible as the first instance of the multiple Evidence objects. Updates to 13.0 make it possible to continue using Release Evidence and to be able to leverage on demand evidence collection.
Removal date:
May 22, 2020
Remove --docker-services flag on register command
In GitLab Runner 12.7 we introduced the ability to allow a service alias from config in the Docker executor. In 13.0, the old structure (--docker-services) has been removed. This means that the option gitlab-runner register --docker-services postgres will no longer set the service, because the configuration is no longer an array of strings. You can find more details in issue #6404.
Removal date:
May 22, 2020
Remove Backported `os.Expand`
In GitLab Runner 13.0, we have removed the backported os.Expand() from Go v1.10.8. This backport was needed to include a change in behavior introduced in Go v1.11. You can find more details in issue #4915.
Removal date:
May 22, 2020
Remove Fedora 29 package support
Since Fedora 29 has reached End of Life as of 2019-11-30, we have removed support for Fedora 29 packages in the GitLab Runner 13.0 release. You can find more details in issue #16158.
Removal date:
May 22, 2020
Remove Jenkins CI(deprecated) Service
In GitLab 8.3, the Jenkins integration using the GitLab Hook Plugin was deprecated in favor of the GitLab Plugin. In 13.0, this Jenkins CI(deprecated) service is removed in issue #1600.
Removal date:
May 22, 2020
Remove `FF_USE_LEGACY_VOLUMES_MOUNTING_ORDER` feature flag
In 12.0, we introduced a feature flag for the Docker executor that enabled you to continue using the method where volumes are not mounted to services. In 13.0, this feature flag has been removed and volumes will be mounted to services. You can find more details in issue #6581.
Removal date:
May 22, 2020
Remove legacy build directory caching
In GitLab Runner 13.0, we have removed the legacy build directory caching feature flag that was introduced in 11.10. You can find more details in issue #4180.
Removal date:
May 22, 2020
Remove macOS 32-bit support
As Go 1.14 is the last Go release to support 32-bit binaries on macOS (the Darwin/386 port), we have removed support for 32-bit macOS in the GitLab 13.0 release. GitLab Runner will continue to support the macOS 64-bit Darwin/AMD64 port. You can find more details in issue #25466.
Removal date:
May 22, 2020
Remove support for Windows Server 1803
We have removed support for Windows Server version 1803 in the GitLab Runner 13.0 release. You can find more details in issue #6553.
Removal date:
May 22, 2020
Remove support for array of strings when defining services for Docker executor
In GitLab Runner 13.0, we have reverted back to using the default TOML parsing instead of UnmarshalTOML for the DockerService. You can find more details in issue #4922.
Removal date:
May 22, 2020
Removed `debug/jobs/list?v=1` endpoint
In GitLab Runner 13.0, we have removed the /debug/jobs/list?v=1 endpoint used for monitoring. This is superseded by the /debug/jobs/list?v=2 endpoint. You can find more details in issue #6361.
Removal date:
May 22, 2020
`consul['user']` and `repmgr['user']` attributes removed from `gitlab.rb`
The consul['user'] and repmgr['user'] attributes were deprecated in favor of consul['username'] and repmgr['username'] in 12.10 to be consistent with other GitLab services that allow a username to be configured. These attributes have been removed in 13.0. If you are still using the user attributes you will need to switch over to using the username attributes.
Removal date:
May 22, 2020
`gitlab_monitor` attribute removed from `gitlab.rb`
The GitLab Monitor tool was renamed GitLab Exporter in 12.3 to prevent confusion with other monitoring-related features, and gitlab_exporter keys were added to gitlab.rb. The gitlab_monitor keys were deprecated in 12.3 and have been removed in 13.0.
Removal date:
May 22, 2020
Believe it
Get unlimited access to all JiHu GitLab Premium features for 60 days.
