Release 13.4 released with HashiCorp repository for CI variables, Kubernetes Agent and security center, and switchable features in Starter
At GitLab, we're always thinking about how you can help users mitigate risk, improve efficiency, and deliver faster on your favorite platform. This month, we've added a lot of great new features that improve security, reduce vulnerabilities, improve efficiency, make GitLab easier to use, and help your team deliver features even faster. We hope that you will find the main features of the release useful, as well as 53 other new featuresadded in this release.
Advanced security options
We try to add a few new features to GitLab DevSecOps every month, and this release is no exception. during assembly and deployment. In addition, organizations that wish to support segregation of code deployment duties can now . This role corresponds and will allow you to confirm merge requests (in the Russian localization of GitLab, βmerge requestsβ) and deploy code in secure environments, without providing access to change the code itself.
Another way to reduce risk is to use new . Operations professionals can deploy Kubernetes clusters from GitLab without having to expose their cluster to the entire internet. We are also introducing automatic version control support for new Terraform state files with to support compliance and ease of debugging. Finally, the instance's security control panel has evolved into with vulnerability reports and security settings.
More convenient and efficient work with GitLab
We have improved our global search by adding , which allows you to easily navigate to the latest tickets, groups, projects, settings, and help topics. We are happy to announce that in GitLab Pages to redirect individual pages and directories within a site, allowing users to deploy their sites more efficiently. And for those who would like to receive extended information about the deployment, this release allows !
Open source contributions
We represent , which added . Unit test coverage marks for code changes give developers a visual representation of code coverage during reviews; this information helps to speed up reviews and reduce the time to merge and deploy new code. And also we and plan .
And this is just the beginning!
As always, there is too little space in the general overview, and there are a lot of cool features in release 13.4. Here are a few more:
- .
If you want to know in advance what awaits you in following release, see .
.
this month -
Fabio has contributed significantly Π² - a feature that has been waiting for a very long time in the GitLab community. This is a really important contribution with non-trivial changes that required constant collaboration with members of the GitLab team and affected many areas of the project, such as UX, front-end and back-end.
Main features of GitLab 13.4 release
Use HashiCorp Vault Keys in CI Jobs
(PREMIUM, ULTIMATE, SILVER, GOLD)
In release 12.10, GitLab introduced the ability to receive and pass keys to CI jobs using the GitLab job handler (GitLab runner). Now we are expanding , adding new syntax secrets to file .gitlab-ci.yml. This will make it easier to set up and use the HashiCorp repository with GitLab.
ΠΈ .
Introducing GitLab Kubernetes Agent
(PREMIUM, ULTIMATE)
GitLab's integration with Kubernetes has long allowed deployment on Kubernetes clusters without the need for manual configuration. Many users liked the ease of use of this bundle, while others encountered some difficulties. For ongoing integration, your cluster must be accessible from the internet so that GitLab can access it. For many organizations, this is not feasible because they restrict access to clusters for security, compliance, or regulatory reasons. To get around these limitations, users needed to build their tools on top of GitLab, otherwise they wouldn't be able to use this feature.
Today we're introducing the GitLab Kubernetes Agent, a new way to deploy to Kubernetes clusters. The agent runs inside your cluster, so you don't need to expose it to the entire internet. The agent coordinates the deployment by requesting new changes from GitLab instead of GitLab pushing updates to the cluster. No matter which GitOps method you use, GitLab is right for you.
Please note that this is the first release of the agent. Currently, we have focused GitLab Kubernetes Agent on configuring and managing deployment through code. Some existing Kubernetes integration features, such as deployment boards and GitLab-managed applications, are not yet supported. that these capabilities will be added to the agent in future releases, as well as new integrations focused on security and compliance.
ΠΈ .
Give users permissions to deploy without code access
(PREMIUM, ULTIMATE, SILVER, GOLD)
Previously, the permission system in GitLab did not allow you to properly divide responsibilities in your team between those who are responsible for development and those who are responsible for deployment. With the release of GitLab 13.4, you can give permission to confirm merge requests for deployment, as well as to actually deploy the code to people who do not write code, while not granting them maintainer access (in the Russian localization of GitLab, "maintainer").
ΠΈ .
Security Center
(ULTIMATE, GOLD)
Previously, instance-level vulnerability management was limited in both functionality and flexibility. The interface was a single page that combines vulnerability details, metrics graphs, and settings. There isn't much room to develop these features or use other security features.
We have made fundamental changes to security management and security transparency in GitLab. The instance security panel has been transformed into a whole security hub. The biggest change is the introduction of a new menu structure: instead of one page, you now see the security control panel, the vulnerability report, and the settings section separately. While the functionality hasn't changed, breaking it down will allow improvements to this section that would otherwise be difficult. It also sets the stage for other security-related features to be added in the future.
The dedicated vulnerability reporting section now has more space to display important details. The vulnerabilities that are currently on the project's list of vulnerabilities are collected here. Moving widgets with vulnerability metrics to a separate section creates a convenient security control panel. It is now a canvas for future visualizations - not just for vulnerability management, but for any security-related metrics. Finally, a dedicated settings area creates a common space for all instance-level security settings, not just vulnerability management.
ΠΈ .
Switchable features are now in GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab 11.4 has been released . In 12.2 we introduced strategies for them ΠΈ , and in 13.1 added ΠΈ for different environments.
Earlier this year, GitLab committed to into open source. In this release, we have completed the transfer of switchable features to the Starter plan and will continue to transfer them to Core with . We're excited to bring this feature to more users and want to know how you'll use it.
ΠΈ .
Quick navigation from the search bar
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Sometimes, when navigating through GitLab, you want to go straight to a specific project instead of the search results page.
With the global search bar, you can quickly navigate to the latest tickets, groups, projects, settings, and help topics. You can even use hotkey /to move the cursor to the search bar to navigate GitLab even more efficiently!
ΠΈ .
Display code coverage in merge request diffs
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
When reviewing a merge request, it can be difficult to determine whether the changed code is covered by unit tests. Instead, reviewers can rely on the overall coverage and require it to be increased before approving the merge request. This can lead to a haphazard approach to writing tests that doesn't really improve code quality or test coverage.
Now, when viewing a merge request diff, you will see a visual display of code coverage. The new marks will allow you to quickly understand if the changed code is covered by a unit test, which will help speed up code reviews and the time to merge and deploy new code.
Thank you and Siemens for this feature!
ΠΈ .
More environments and projects in the environments panel
(PREMIUM, ULTIMATE, SILVER, GOLD)
Since the release of GitLab 12.5 with you could track the status of environments, but not more than seven environments in three projects. We improved this panel in release 13.4 by paginating it to help you maintain and manage your environments at scale. Now you can see more environments in more projects.
ΠΈ .
GitLab Takes Control of GitLab Terraform Provider
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Recently we and plan . Over the past month, we have accepted 21 merge requests and closed 31 tickets, including some long-standing bugs and missing features, such as . You can in the Terraform documentation.
ΠΈ .
Fuzz API testing with OpenAPI specifications or HAR file
(ULTIMATE, GOLD)
API fuzz testing is a great way to find bugs and vulnerabilities in your web applications and APIs that other scanners and testing methods might miss.
Fuzzing API testing in GitLab allows you to provide or your application and then automatically generates random inputs for edge case testing and error hunting. The results are immediately displayed within your pipeline.
This is our first release of fuzzing API testing and we'd love to hear what you think. For fuzzing testing, we have more in stock , which we will base on the release of this feature.
ΠΈ .
Preview new graphs in the metrics panel
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In the past, creating a graph in a metrics dashboard in GitLab was a daunting task. After you created the metric in the panel's YAML file, you made changes to master, without being able to verify that the graph you just created works exactly as you wanted. Starting with this release, you can preview changes as you create a graph, getting an idea of ββthe result before submitting changes to the panel's .yaml file.
ΠΈ .
Data on code coverage by tests for all projects of the group
(PREMIUM, ULTIMATE, SILVER, GOLD)
When you manage a large number of projects in GitLab, you need a single source of information about how code coverage changes across projects over time. Previously, displaying this information required tedious and time-consuming manual work: you had to download code coverage data from each project and combine them in a table.
In release 13.4, it became possible to easily and quickly compile into .csv file all data on code coverage for all projects of the group or for a selection of projects. This feature is MVC, it will be followed by the possibility .
ΠΈ .
Support for new languages ββfor full fuzz testing
(ULTIMATE, GOLD)
This release introduces support for several new languages ββfor fuzz testing aimed at full coverage.
Now you can explore all the possibilities of fuzz testing in your Java, Rust and Swift applications and find bugs and vulnerabilities that other scanners and testing methods might miss.
ΠΈ .
Notifications on the main page of environments
(PREMIUM, ULTIMATE, SILVER, GOLD)
The environments page shows the general state of your environments. In this release, we have improved this page by adding the display of alerts. Triggered alerts along with the status of your environments will help you take corrective action faster.
ΠΈ .
Nested pipelines can now run their own nested pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
When using nested pipelines, it became possible to run new pipelines inside child pipelines. The extra level of depth can be useful if you need the flexibility to generate a variable number of pipelines.
Previously, when using nested pipelines, each child pipeline required a trigger job that was manually defined in the parent pipeline. Now you can create nested pipelines that will dynamically start any number of new nested pipelines. For example, if you have a monorepo, you can dynamically generate the first nested pipeline, which itself will create the required number of new pipelines based on changes in the branch.
ΠΈ .
Improved navigation between parent and nested pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Moving between parent and nested pipelines was previously not very convenient - it took a lot of clicks to get to the desired pipeline. It was also not easy to figure out exactly which job started this pipeline. Now it will be much easier to see the relationships between parent and nested pipelines.
ΠΈ .
Parallel Matrix Jobs Show Relevant Variables in Job Title
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
If you used , you may have noticed that it was difficult to determine which matrix variable was used for which job, as the job names looked like matrix 1/4. In release 13.4, you will see the relevant values ββof the variables that were used in this job, instead of the generic name of the job. For example, if your goal is to debug for the x86 architecture, then the task will be called matrix: debug x86.
ΠΈ .
Other improvements in GitLab 13.4
Connecting an Atlassian account
(CORE, STARTER, PREMIUM, ULTIMATE)
GitLab users will now be able to connect their GitLab accounts to an Atlassian Cloud account. This will allow you to log in to GitLab with your Atlassian credentials, as well as lay the foundation for future integration improvements. and with other products from the Atlassian line.
ΠΈ .
Export a list of all merge commits
(ULTIMATE, GOLD)
Compliance organizations need a way to show auditors a holistic view of the components associated with any given production change. Within GitLab, this means gathering everything in one place: merge requests, tickets, pipelines, security scans, and other commit data. Until now, you either had to manually collect this in GitLab, or set up your tools to collect information, which was not very efficient.
Now you can programmatically capture and export this data to meet your auditing or other needs. To export a list of all merge commits for the current group, you need to navigate to and click on the button List of all merge commits. The resulting file will contain all merge request commits, their author, associated merge request ID, group, project, committers, and other information.
ΠΈ .
Listing and managing personal access tokens via API
(ULTIMATE, GOLD)
Managing access to the GitLab namespace is an important part of the compliance effort. From principles of least privilege to disabling timed access, there can be several requirements related to personal access tokens in GitLab. To make it easier to maintain and manage all of these user credentials within your namespace, we have provided the ability to list all private access tokens and optionally through the API.
These enhancements to the GitLab API allow users to list and revoke their own personal access tokens, and administrators to list and revoke their users' tokens. It will now be easier for administrators to see who has access to their namespace, make access decisions based on user data, and revoke personal access tokens that may have been compromised or that fall outside the company's access control policies.
ΠΈ .
Related tickets and other features are now in GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A few months ago we announced a plan to . Working to fulfill this promise, we have made , ΠΈ (in the Russian localization of GitLab "discussion board") available in the Core plan. This only applies to relationships of the type βassociated withβ, relationships of the type βblocksβ and βblocksβ remain in paid plans.
ΠΈ .
Displaying the name of the source branch in the merge request sidebar
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
When reviewing code changes, discussions, and merge request commits, it is often desirable to checkout the branch locally for deeper review. However, finding the branch name becomes more and more difficult as more content is added to the merge request description and the page has to be scrolled further and further.
We've added the branch name to the sidebar of the merge request, making it available at any time and eliminating the need to scroll through the entire page. Like the merge request link, the source branch section contains a handy "copy" button.
Thank you for the huge contribution to the development of this feature!
ΠΈ .
Indication of the presence of collapsed files in merge request diffs
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Merge requests that add changes to multiple files sometimes collapse large file diffs to improve display performance. When this happens, it's possible to accidentally skip a file when reviewing, especially in merge requests with a large number of files. Starting with version 13.4, merge requests will flag diffs that contain folded files, so you won't miss those files during the code review process. For even greater clarity, we plan to add highlighting of these files in a future release. Stay tuned for updates at .
ΠΈ .
Warning about the presence of collapsed files in a merge request diff
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In the merge request diff section, large files are collapsed to improve performance. However, when reviewing the code, some files may be skipped when the reviewer scrolls through the list of files, since all large files are collapsed.
We have added a visible warning at the top of the merge request diff page to inform users that there is a merged file in that section. This way you won't miss any changes in the merge request during the review.
ΠΈ .
Automatic recovery of the Gitaly cluster repository
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Previously, when the primary node of a Gitaly cluster went down, the repositories on that node were marked as read-only. This prevented data loss in situations where there were changes on the node that had not yet been replicated. When the node reconnected, GitLab did not automatically recover, and administrators had to manually start the synchronization process or put up with data loss. Other situations could also lead to outdated or read-only repositories, such as the failure of a replication job on a secondary node. In this case, the repository remained out of date until the next write operation was performed, which would start the replication job.
To solve this problem now schedules a replication job when it detects an outdated repository on one node and the latest version of a repository on another. This replication job keeps the repository up to date automatically, eliminating the need to manually restore data. Automatic recovery also ensures that secondary nodes are quickly brought up to date if a replication job fails, instead of waiting for the next write operation. Since many Gilaly clusters store a large number of repositories, this significantly reduces the time that administrators and reliability engineers spend on data recovery after an error.
In addition, auto-fix starts replicating repositories on any new Gitaly node added to the cluster, eliminating the manual work of adding new nodes.
ΠΈ .
Mark the to-do task as done on the design page
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Effective communication in GitLab is based on to-do lists. If you've been mentioned in a comment, it's critical to be able to navigate to a task and either start doing something or mark it as done. It's also important to be able to assign a task to yourself when you need to work on something or come back to it later.
Previously, you couldn't add tasks or mark them as done while working on designs. This seriously disrupted the effectiveness of communication between product teams, since to-do tasks are a critical element of the workflow in GitLab.
In release 13.4, designs are catching up with ticket comments in the use of tasks, making them more consistent and efficient.
ΠΈ .
Improved Troubleshooting Guide for CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
We've improved the GitLab CI/CD Troubleshooting Guide by adding additional information about common issues you may encounter. We hope the improved documentation will be a valuable resource to help you quickly and easily set up and run GitLab CI/CD.
ΠΈ .
Merge requests are no longer dropped from the merge queue
(PREMIUM, ULTIMATE, SILVER, GOLD)
Previously, merge requests could fall out of the merge queue by accident due to late comments. If a merge request was already in the queue and someone added a comment to it that created a new unresolved discussion, the merge request was considered unsuitable for merge and dropped out of the queue. Now, after a merge request is added to the merge queue, new comments can be added without fear of breaking the merge process.
ΠΈ .
Displaying the code coverage value for a job in a merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Developers should be able to see the code coverage value after the pipeline has completedβeven in complex scenarios such as running a pipeline with multiple jobs that need to be parsed to calculate the coverage value. Previously, the merge request widget only showed the average of these values, which meant that you had to go to the job page and back to the merge request to get intermediate coverage values. To save you time and these unnecessary steps, we have made the widget display the average coverage value, its changes between the target and source branches, and a tooltip that shows the coverage value for each task, on the basis of which the average was calculated.
ΠΈ .
Removing packages from the package registry when viewing a group
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
The GitLab Package Registry is a place to store and distribute packages in different formats. When your project or group has a lot of packages, you need to quickly identify unused packages and remove them so people don't download them. You can remove packages from your registry via or through the package registry UI. However, until now, you could not delete packages when viewing a group through the user interface. As a result, you had to remove redundant packages on a per-project basis, which was inefficient.
You can now remove packages when viewing a group's package registry. Just go to the group's package registry page, filter packages by name, and remove any you don't need.
ΠΈ .
Scaling Conan Packages to Project Level
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
You can use the GitLab Conan repository to publish and distribute C/C++ dependencies. However, previously packages could only be scaled to the instance level, as the Conan package name could be a maximum of 51 characters. If you wanted to publish a package from a subgroup like gitlab-org/ci-cd/package-stage/feature-testing/conan, it was almost impossible to do.
You can now scale Conan packages to the project level, making it easy to publish and distribute your project's dependencies.
ΠΈ .
Support for new package managers and languages ββfor dependency scanning
(ULTIMATE, GOLD)
We're excited to add dependency scanning for projects with C, C++, C#, and .Net code that use NuGet 4.9+ or the Conan package managers to our list. . You can now enable dependency scanning as part of the Secure stage to check dependencies added via package managers for known vulnerabilities. Found vulnerabilities will be displayed in your merge request along with their severity level, so that you know before the merge what risks a new dependency carries. You can also customize your project to require for dependencies with critical (Critical), high (High), or unknown (Unknown) vulnerabilities.
ΠΈ .
Notifications when changing the merge request setting to 'Merge on successful completion of the pipeline'
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Previously, when setting the merge request setting Merge when pipeline finishes (Merge When Pipeline Succeeds, MWPS) no email notification was sent. You had to manually check the status or wait for the merge to be notified. In this release, we are pleased to present the user's contribution , which solved this problem by adding automatic notifications to everyone who subscribed to the merge request when the reviewer changes the merge setting to MWPS.
ΠΈ .
Creating EKS Clusters with User Defined Kubernetes Version
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab users can now choose the version of Kubernetes that will be provided by EKS; you can choose between versions 1.14-1.17.
ΠΈ .
Creating Incidents as Ticket Types
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Not every issue that occurs immediately triggers alerts: Users report outages, and team members investigate performance issues. Incidents are now a form of a ticket so your teams can quickly create them as part of a familiar workflow. Click New task from anywhere in GitLab, and in the field A type select Incident.
ΠΈ .
Mentioning GitLab Alerts in Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
We've improved GitLab alerts by adding a new mention type specifically for them in the GitLab version of Markdown, making it easier to share and mention alerts. Use ^alert#1234to mention the alert in any Markdown field: in incidents, tickets, or merge requests. It will also help you define issues that are created from alerts, not from tickets or merge requests.
ΠΈ .
View Incident Alert Load
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
The alert description contains information critical to failure diagnosis and recovery, and this information should be easily accessible so that you don't have to switch tools or tabs while working to resolve an incident. Incidents created from alerts display the full description of the alert in a tab Alert Details.
75% faster advanced search
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab, as a single application, has the unique ability to make content discovery across the entire DevOps workflow fast. In GitLab 13.4, advanced search returns results 75% faster when it , like on GitLab.com.
ΠΈ .
Viewing Remote Projects for Administrators
(CORE, STARTER, PREMIUM, ULTIMATE)
The ability to delay deleting a project was . However, previously it was not possible to see all the projects waiting to be deleted in one place. GitLab custom instance administrators can now view all pending deletion projects in one place, along with buttons to easily restore those projects.
This feature gives administrators greater control over deleting projects by gathering all relevant information in one place and providing the ability to undo unwanted deletions.
Thank you for this feature!
ΠΈ .
Added support for group push rules to the API
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Previously, group push rules could only be configured by visiting each group individually through the GitLab UI and applying those rules. You can now manage these rules via an API to support your custom tools and GitLab automation.
ΠΈ .
Revoke personal access tokens for self-managed credential storage
(ULTIMATE)
provides administrators with the information they need to manage user credentials for their GitLab instance. Because compliance-oriented organizations vary in the strictness of their credential management policies, we've added a button that allows administrators to revoke a user's Personal Access Token (PAT) if desired. Administrators can now easily revoke potentially compromised PATs. This feature is useful for organizations that need more flexible enforcement options to minimize distractions for their users.
ΠΈ .
Configuration file for the static site editor
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab 13.4, we're introducing a new way to customize the static site editor. Although the configuration file does not store or retrieve any settings in this release, we are laying the groundwork for future customization of the editor's behavior. In the next releases we will add to the file .gitlab/static-site-editor.yml parameters to install Where , overriding Markdown syntax settings and other editor settings.
ΠΈ .
Editing the introductory part of a file using the static site editor
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Front matter is a flexible and convenient way to define page variables in data files to be processed by the static site generator. It is typically used to set the page's title, layout template, or author, but can be used to pass any type of metadata to the generator when rendering the page to HTML. Included at the very top of every data file, the preamble is usually formatted as YAML or JSON and requires a consistent and precise syntax. Users unfamiliar with specific syntax rules may inadvertently enter invalid markup, which in turn may cause formatting problems or even build failures.
The WYSIWYG editing mode of the static site editor already removes the intro from the editor to prevent these formatting errors. However, this prevents you from changing the values ββstored in that part without reverting to editing in source mode. In GitLab 13.4, you can access any field and edit its value in a familiar form-based interface. When you press a button Setting (Settings) opens a panel that displays a form field for each key defined at the beginning. The fields are filled with the current value, and to edit any of them, simply enter it in the web form. This preface editing avoids syntax complexity and gives you full control over the content, while ensuring that the final output is formatted consistently.
ΠΈ .
GitLab for Jira and DVCS Connector now in Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
For Jira users in GitLab: ΠΈ allow you to display information about GitLab commits and merge requests directly in Jira. Combined with our built-in Jira integration, you can easily move between the two apps while you work.
These features were previously only available in our Premium plan, but now they are available to all users!
ΠΈ .
Majority Voting for Gitaly Cluster Transactions (Beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
A Gitaly cluster allows you to replicate Git repositories to multiple warm Gitaly nodes. This improves fault tolerance by eliminating single points of failure. , introduced in GitLab 13.3, causes changes to be broadcast to all Gitaly nodes in the cluster, but only Gitaly nodes that vote in agreement with the primary node save the changes to disk. If all replica nodes do not agree, only one copy of the change will be saved to disk, creating a single point of failure until asynchronous replication is complete.
Majority voting improves resiliency by requiring majority (rather than all) nodes to agree before changes are saved to disk. If this switchable feature is enabled, the write should succeed on multiple nodes. Disagreeing nodes are automatically synchronized using asynchronous replication from those nodes that formed a quorum.
ΠΈ .
Support for custom schema for JSON validation in Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
Projects where people write configurations in JSON or YAML format are often prone to problems because it's easy to make a typo and break something. It is possible to write validation tools that catch these issues in the CI pipeline, but using a JSON schema file can be helpful to provide documentation and hints.
Project members can define in their repository the path to the custom schema in the file .gitlab/.gitlab-webide.yml, which specifies the schema and path to the files to check. When a particular file is uploaded to the Web IDE, additional feedback and validation will be visible to help create the file.
ΠΈ .
Directed Acyclic Graph (DAG) branching limit increased to 50
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
If you are using pipelines (Directed Acyclic Graph (DAG)), you might find that there is a limit of 10 jobs that a job can specify in needs:, too harsh. In 13.4, the default limit has been increased from 10 to 50 to allow for more complex networks of relationships between jobs in your pipelines.
If you're the administrator of a GitLab custom instance, you can raise this limit even higher by setting up a switchable feature, although we don't offer official support for this.
ΠΈ .
Improved behavior needs for missed tasks
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In some cases, a skipped job in a pipeline could erroneously be considered successful for the dependencies listed in needs, causing subsequent jobs to run when they shouldn't. This behavior has been fixed in version 13.4, and needs now correctly handles cases of skipped tasks.
ΠΈ .
Pin the last job artifact to prevent it from being deleted
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab now automatically locks the last artifact of a successful job and pipeline on any active branch, merge request, or tag to prevent it from being deleted after it expires. It's becoming easier to set more aggressive expiration rules to clean up old artifacts. This helps reduce disk space consumption and ensures that you always have a copy of the latest artifact from the pipeline.
ΠΈ .
CI/CD guide to pipeline optimization
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Optimizing the CI/CD pipeline can improve delivery speed and save money. We've improved our documentation with a quick guide to getting the most out of optimizing your pipelines.
ΠΈ .
Test report sorted by test status
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
is an easy way to see the results of all the tests in the pipeline. However, with a large number of tests, finding failed tests can take a long time. Other issues that can make the report difficult to use include difficulty scrolling through long trace output and rounding time to zero for tests that run in less than 1 second. Now, by default, the sorting test report first puts failed tests at the top of the report, and then sorts the tests by duration. This makes it easier to find crashes and lengthy tests. In addition, test durations are now displayed in milliseconds or seconds, making them much faster to read, and previous scrolling issues have also been resolved.
ΠΈ .
File Size Limits Uploaded to the Package Registry
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
There are now limits on the size of package files that can be uploaded to the GitLab Package Registry. Limitations have been added to optimize package registry performance and prevent abuse. Limitations depend on the package format. For GitLab.com, the maximum file sizes are:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
For custom GitLab instances, the defaults are the same. However, the administrator can update the restrictions with .
ΠΈ .
Use CI_JOB_TOKEN to publish PyPI packages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
You can use the GitLab PyPI repository to create, publish, and share Python packages along with source code and CI/CD pipelines. However, previously you could not authenticate against a repository with a predefined environment variable CI_JOB_TOKEN. As a result, you had to use your personal credentials to update the PyPI repository, or you may have decided not to use the repository at all.
It is now easier to use GitLab CI/CD to publish and install PyPI packages using a predefined environment variable CI_JOB_TOKEN.
ΠΈ .
DAST scanner profiles on request
(ULTIMATE, GOLD)
To the on-demand DAST scan that was , DAST scanner profiles have been added. They expand the configuration options for this scan by allowing you to quickly create multiple profiles to cover multiple scan types. In 13.4, the crawler profile initially includes a crawler timeout setting that sets how long the DAST crawler should run when it tries to discover all the pages of a crawled site. The profile also includes a target site timeout setting to set how long the crawler should wait for a site to become available before aborting the crawl if the site does not respond with a 200 or 300 status code. As we improve over and over again this feature in future releases, additional configuration options will be added to the scanner profile.
ΠΈ .
A simple redirect configuration file for GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
If you are using GitLab Pages and want to better manage URL changes, then you may have noticed that it was not possible to manage redirects on your GitLab Pages site. GitLab now allows you to set up rules for redirecting one URL to another for your Pages site by adding a configuration file to the repository. This feature was made possible by the contributions of Kevin Barnett (), our Eric Eastwood () and GitLab commands. Thanks everyone for your input.
ΠΈ .
Terraform state managed by GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Access to previous versions of Terraform's state is necessary for both compliance and debugging as needed. Support for GitLab-managed Terraform state versioning has been provided since GitLab 13.4. Versioning is enabled automatically for new Terraform state files. Existing Terraform state files will be in a later release.
ΠΈ .
Important Details of Incident Reporting
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
When handling incidents, you need to be able to easily determine how long an alert has been open and how many times an event has fired. These details are often critical in determining customer impact and what your team should do first. In the new incident details panel, we display the start time of the alert, the number of events, and a link to the original alert. This information is available for incidents that are generated from alerts.
ΠΈ .
Setting and editing the incident severity parameter
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
The Incident Severity dimension allows responders and stakeholders to determine the impact of an outage, as well as the methods and urgency of the response. As your team shares results during incident resolution and recovery, they may change this setting. You can now edit the severity of an incident in the right sidebar of the Incident Details page, and the severity is displayed in the list of incidents.
ΠΈ .
Create, edit, and delete container network security rules
(ULTIMATE, GOLD)
This enhancement to the Container Network Security Rule Editor allows users to easily create, edit, and delete their own rules right from the GitLab UI. Editor features include mode .yaml for advanced users and a rules editor with an intuitive interface for those new to network rules. You can find new rules management features in the section Security & Compliance > Threat Management > Rules (Security & Compliance > Threat Management > Policies).
ΠΈ .
Azure blob storage support
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Both GitLab and GitLab Runner now support , which makes it easy to run GitLab services on Azure.
GitLab instances support Azure for all types of object storage, including LFS files, CI artifacts, and . To set up Azure blob storage, follow the installation instructions or .
GitLab job processors also support Azure for storage . Azure storage can be configured using the section .
ΠΈ .
Omnibus ARM64 packages for Ubuntu and OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
In response to the growing demand for GitLab running support for 64-bit ARM architecture, we are pleased to announce the availability of the official ARM64 Ubuntu 20.04 Omnibus package. Huge thanks to Zitai Chen and Guillaume Gardet for the huge contribution they have made - their merge requests have been a key part of this!
To download and install the package for Ubuntu 20.04, go to our and then Ubuntu.
ΠΈ .
Support for smart card authentication for GitLab Helm chart
(PREMIUM, ULTIMATE)
Smart cards, such as Shared Access Cards (CACs), can now be used to authenticate to a GitLab instance deployed via Helm chart. Smart cards are authenticated against a local database using X.509 certificates. With this, smart card support with Helm chart is now in line with smart card support available in Omnibus deployments.
ΠΈ .
Detailed release notes and upgrade/installation instructions can be found in the original English post: .
Worked on the translation from English , , ΠΈ .
Source: habr.com