GitLab 13.2 released with Planning Iterations and Load Performance Testing
GitLab 13.2 released with iterations for milestones, diff changes for wiki pages, PHP Composer package support, load performance testing, and much more!
GitLab 13.2 now helps teams streamline project planning with milestone iterations, collaborate better for faster feedback with diff changes for wiki pages, and improve overall performance/efficiency with load performance testing.
Streamline agile project planning and management
Managing workflows and planning tasks for different teams can add a significant amount of development disruption to your day. In releasing our Minimal Viable Change (MVC) of iterations to break down work into smaller, more manageable, chunks, we're lessening this disruption and making project planning easier – with many enhancements to come. If your team leverages Jira for project management, it's now easier for you to view Jira issues in GitLab because we believe that GitLab should play well with others and balance integrations with native capabilities. If you're using epics to plan and manage large projects, then you can now protect sensitive content with confidential epics. When you need to update several related epics, you can now bulk edit epics to reduce your "tab overload" and the number of clicks it takes to update.
Better collaboration for faster feedback
Clear communication is key to effective collaboration because it enables development teams to get faster feedback on changes before pushing them to production. The ability to diff changes for wiki pages now makes edit history comparisons between page versions quicker and simpler, similar to viewing files in a repository. Realtime feedback for.gitlab-ci.ymlin the Web IDE makes updating your CI pipeline more efficient by enabling realtime linting and autocompletion. Now you don't have to remember all of the parameters when configuring your CI pipeline or switch contexts to get the information you need.
Designers are incredibly important members of the team and 13.2 includes great improvements to design management. It's now easier to find designs in an issue so it takes less time, and the official GitLab Figma plugin simplifies the process of uploading from Figma to issues on GitLab.com.
Improved performance and efficiency
13.2 delivers new updates to improve your team's efficiency and performance. You can now take advantage of advanced global search on GitLab.com, a capability that improves search relevancy, performance, and allows for group-wide searches across all projects directly in the UI. Application performance is a challenge every development team faces and now load performance testing in GitLab makes it easy to run custom load tests as part of your CI/CD pipelines to better understand how your application will perform under stress.
Nowadays, it seems like everyone is working from home and are "distributed" more than ever. GitLab Geo helps remote teams work more efficiently by using a local GitLab node, and now offers improved replication performance for projects to ensure local content is fresh. Last but not least, GitLab includes CI test results within Release Evidence for easy access in the event you need to provide compliance data or a more efficient way to show relevant changes to production during audit.
Jesse contributed the new Batch Suggestions
feature which allows MR reviewers to group all suggestions made to a diff and submit them at once. Because each
suggestion translates into a Git operation, submitting these individually could take a long time if there
were a large number of suggestions. Submitting suggestions in batches has numerous advantages, including time
savings, efficient CI resource utilization (only one pipeline for all suggestions), and preventing an overly
noisy Git history.
Thank you Jesse for the great effort, patience, and persistence getting this one over the line. We greatly
appreciate it.
Prior to this release, there was no way to associate an issue with more than one timebox in GitLab. This has been particularly problematic for teams that follow Scrum or XP. Such teams often need to associate issues with iterations/sprints, while also rolling that issue up to longer-running milestones, such as program increments.
Instead of having to decide whether to use milestones for sprints or program increments and track the other in a spreadsheet, you can now assign issues to iterations, milestones, or both.
This is the first MVC towards a longer term
vision
we have for empowering teams to more effectively use timeboxes to move
from plan-driven to value-driven development.
We’re pleased to announce the first release of Container Host Security.
This initial feature, container host monitoring and blocking, allows security administrators
to secure their running containers at the host level by monitoring and optionally
blocking unexpected activity. Such activity includes process starts, file changes,
or opened network ports. This feature uses Falco to provide the monitoring functionality
and AppArmor and
Pod Security Policies for the blocking functionality.
Recently, the GitLab product design team and our open source Pajamas Design System switched over to Figma. We decided to build a new Figma plugin, which allows for easy uploads from Figma to issues on GitLab.com. This makes it quick and easy to collaborate on Designs. Connect your design environment with your source code management in a seamless workflow.
In 13.2 we launched the official plugin on the Figma directory:
To understand system performance, your development team must monitor the health and performance of the underlying infrastructure. We want our metrics solution to be available to all GitLab users, so as part of our 2020 gift, we’ve moved cluster health in the Monitor stage from GitLab Ultimate to GitLab Core. Beginning with GitLab 13.2, all users can connect a cluster and monitor its health in the GitLab user interface.
PHP developers need a mechanism to share and consume their projects’ dependencies. Composer is a dependency manager for PHP that allows you to declare the libraries your project depends on and it will manage them for you.
We are proud to offer a Composer Repository built directly into GitLab. PHP Developers now have an easier way to discover and manage their projects’ dependencies. By integrating with Composer, GitLab provides a centralized location to view those packages in the same place as source code and pipelines. PHP dependencies in the Package Registry will be listed under the All tab and not under a Composer-specific tab. We will iterate to improve this by adding a Composer-specific tab in an upcoming milestone.
Special thanks to @ochorocho, who has been a significant contributor to this feature. We could not have done it without his help and guidance.
You can now organize a collection of related confidential issues into a
confidential epic. For customers working in areas like finance, HR, or security, there is often
a need to work on items that can’t be public or openly viewable. To better support customers
managing multiple confidential issues that all roll up to a shared goal or project, we have expanded our
confidential functionality to epics!
GitLab customers and contributors that use IBM mainframes are adopting modern DevOps practices and want to be able to run GitLab Runners directly on their hardware. Based on this growing interest to expand platform support for z/OS mainframes, we’ve included the first version of a GitLab Runner binary Docker and helper image that you can use to run and execute Continuous Integration jobs natively on the s390x architecture under a Linux on IBM Z environment.
In large organizations, independent teams may have a common interest in parts of the application,
for instance, a payment processing company may have development, security, and compliance teams
looking after common parts of the codebase. All three teams may need to approve changes.
While Code Owners are applied based on which files are changed, only one CODEOWNERS
pattern can match per file path.
In GitLab 13.2, Code Owner Sections allow each team to configure their own code owners
independently. The section rules may be used for shared paths so that multiple teams can be added as reviewers,
ensuring the right groups are reviewing relevant code will help with increased code quality, while
getting feedback/reviews from the right reviewers will lead to increased efficiency.
We want to make AWS deployments easier. In order to do so, we recently delivered a CI/CD template that deploys to AWS ECS:EC2 targets and even connected it to Auto DevOps. Scaling container instances in EC2 is a challenge, so many users choose to use AWS Fargate instead of EC2 instances. In this release we added Fargate support to the template, which continues to work with Auto DevOps as well, so more users can benefit from it.
Prior to this release, GitLab.com users who wanted to do a cross-project code search would have to clone the repositories and search locally on their machine, a time-consuming and frustrating task.
With GitLab 13.2, Bronze and higher GitLab.com groups can now perform group-wide code searches directly in the UI, by using Advanced Global Search. Advanced Global Search adds the ability to search code across all projects in a group, improves search relevancy and performance, allows scoping, and enables Advanced Search Syntax. This will make the experience of searching for content in GitLab much more powerful, enabling users to more easily find their content.
We have added the ability to associate related issues with their respective feature flags. For example, you can link the issue that introduced the feature flag itself. That relationship is visible in the feature flag details and will make it easier to find the reasons why a flag was originally introduced. It will also make it easier to follow the issue’s milestone and status directly from the feature flag itself to get better visibility into the feature details.
For organizations using Jira as their primary work tracking tool,
it can be a challenge for contributors to work across multiple systems
and maintain a single source of truth.
In this extension of our current Jira integration, project admins can now
choose to display a list of Jira issues natively inside the GitLab
project. This allows developers working primarily in GitLab to remain in
flow, without having to reference a second tool for tracking what work
needs to get done. Further planned enhancements include commenting, status
changes (transitions), and more.
It is important to know how the applications you’re developing will perform under load. For example, do you know if your API can support 1,000 users concurrently? There wasn’t an easy way to test how changes in a Merge Request would impact baseline performance before you merge.
Now, you can make use of Load Performance Testing to run custom load tests. Out of the box Load Performance Testing will report what percentage of the configured Checks pass, the 90th and 95th percentile for Time to First Byte (TTFB) and the average requests per second (RPS). This makes it easy for you to compare the results against a common baseline and see the results directly in the Merge Request before deciding to merge your code.
When triaging an incident or validating the status of your service, you must be able to explore Kubernetes pod logs from across your entire application stack. Previously, the GitLab user interface displayed only the deployed application logs (logs that originate from the application you deployed to a cluster using CI/CD). In GitLab 13.2, you can now also search across your managed application logs directly from the GitLab user interface.
Using GitLab to deploy multiple Kubernetes clusters with GitLab previously required a Premium license. Our community spoke, and we listened: deploying to multiple clusters is useful even for individual contributors. Based on your feedback, starting in GitLab 13.2, you can deploy to multiple group and project clusters in Core.
In 12.10, we introduced a way for you to automatically create release tags from the .gitlab-ci.yml file. Now we’ve made it easier and more natural to use by exposing the release keyword as a step the GitLab Runner can parse. You no longer need to add a script to call the Release API to create a release. Instead, you can simply add the correct parameters to your CI/CD file.
GitLab is expanding our 12.6 Release Evidence feature by adding CI test results. These job artifacts, generated by the pipeline, are automatically included in the release evidence JSON file. As an Ultimate user, you will be able to effortlessly provide an auditor or compliance process with the relevant changes to production. You can download the evidence JSON and show corresponding test results organically as a part of using GitLab without disrupting your normal workflow.
We released Dynamic Child Pipelines back in
GitLab 12.9, which allow you to generate an entire .gitlab-ci.yml file at runtime. This is a great solution for monorepos, for
example, when you want runtime behavior to be even more dynamic.
We’ve now made it even easier to create CI/CD YAML at runtime by including a project template that demonstrates how to use Jsonnet to generate
the YAML. Jsonnet is a data templating language that provides functions, variables, loops, and conditionals that allow for fully
parameterized YAML configuration.
Audit events already capture changes made to merge request approvals. In 13.2, we’re completing the loop by adding details about the changes to approval groups. When changes are made to merge request approval rules, you should now see a more complete view of the changes.
Previously, when an administrator configured the merge request settings in the Admin Area, all projects in the instance inherited those settings. This inheritance model was too broad for customers who wished to apply different, more flexible requirements to non-regulated projects. Now, we’re providing added flexibility by enabling administrators to specify the project compliance framework labels they wish to enforce these instance-level settings on. When selected, only projects with the corresponding compliance framework labels will inherit these settings and they will only be editable at the instance-level by administrators.
This feature allows compliance-minded organizations to ensure this critical separation of duties controls are not editable by unauthorized users, which would create a gap in their compliance posture. This is a feature for self-managed customers only for now, but we plan to extend this functionality to GitLab.com group owners as a necessary compliance control for maintaining separation of duties.
You can now toggle enforcement of PAT credential expiration when a lifetime limit is defined and met or exceeded by a personal access token. This optional enforcement provides flexibility to organizations for how they wish to manage credential rotations. This change is part of a larger solution to make credential management in GitLab both effective for organizations and friendly for developers.
Often it is necessary to assign multiple issues to an Epic to organize work together. You can now
bulk edit the epic assignment for multiple issues at once. You can do this from the Issues List,
which reduces the number of tabs and clicks required to properly assign work to the right epic.
When importing issues from Jira to GitLab, you can now map Jira users to GitLab project members prior to running the import. This enables the importer to set the correct reporter and assignee on the issues you’re moving to GitLab.
You can now change the relative order of an issue via the REST API. Prior to this release, there was no way to programmatically reorder issues. This has been particularly problematic for API consumers trying to support custom Board interfaces, as it was not possible to change the relative position of issues.
Thank you @jjshoe for adding an endpoint in our public API to support this!
The default order of oldest-to-newest discussions and systems notes is
incredibly helpful for some use cases, such as understanding the history
of a given epic. However, it is much less helpful when teams are in
triage and firefighting mode, as they have to scroll all of the way to the
end of the epic to see the latest updates.
Now you can reverse the default order and interact with the activity
feed with the most recent items at the top. Your preferences for epics
are saved separately in local storage and are automatically applied to
every epic that you view.
When creating a new Git repository, by default the first branch created
is named master.
In coordination with the Git project, broader community, and other Git vendors,
GitLab has been listening to the development community’s feedback on determining
a more descriptive and inclusive name for the default branch, and offering users
options to change the name of the default branch name for their repositories.
GitLab now allows instance administrators to configure the default branch name
for new repositories created through the GitLab interface.
It’s important you get credit for the work you do on designs in GitLab! We’ve added activity for uploading, revising, and commenting on Designs to your user profile, group page, and project page! Keep track of your design operations at a glance.
Code review is an essential practice of every successful project, and giving your
approval once a merge request is in good shape is an important part of the review
process, as it clearly communicates the ability to merge the change. For Core users,
this is usually done by leaving a comment, or giving a thumbs up, but these forms of
approval are easily lost.
In 13.2, anyone with Developer permissions to a project can approve a merge request in
GitLab Core. This makes it obvious to reviewers how to give their approval, and makes
it easy for maintainers to know when a change is ready to merge. Approvals are
optional in GitLab Core and GitLab.com Free, but users of GitLab Starter and
GitLab.com Silver and higher tiers can also
require approvals
to get code merged into the codebase.
If you’re collaborating as a team with Confluence, it can be hard to keep track of both your Confluence Workspace and the GitLab Projects that you use it on. In 13.2, we’ve added a Confluence integration that links your project’s left sidebar directly to a Confluence Workspace in a new tab.
Often Git users heavily rely on file diffs to observe, review, and track changes to content.
In GitLab 13.2, we’ve added support for viewing diffs on Wiki pages. You can seamlessly see
line-by-line content changes between two versions through the wiki commit history.
Projects that use multiple coverage badges, but are calculating different values for each, could only use coverage as the text for every badge. This made it cumbersome to figure out what that value means.
Now, as a project maintainer or owner, you can customize the text for coverage badges to better differentiate between multiple coverage badges displaying on your project.
We’re also releasing GitLab Runner 13.2 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance.
GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.
You can now take advantage of a new group management user interface (UI) for managing your organization’s Runners. In this new UI, you can view, edit, pause, and stop any Runner that’s associated with your group in GitLab. This makes it easier to troubleshoot potential issues with Runners for multiple projects at once.
You can regularly remove older tags from the Container Registry by creating a per-project tag cleanup policy. These policies are based on user-created regular expressions. Unfortunately the container_repository:cleanup_container_repository job that runs against these expressions has been experiencing error rates of 25%. The Gitlab::UntrustedRegexp job considers the regex to be invalid, and when a policy fails to run, no one is notified.
We have taken the first step in resolving this issue. GitLab now validates the regex with the re2 library, so you can’t save an invalid pattern. We also added some common regex patterns to the documentation. You can find more details and our plan for adding future enhancements to this feature based on our roadmap in the epic.
During a single Terraform pipeline, several infrastructure environments might be affected. Previously, GitLab enabled a quick overview of the expected changes in a Merge Request only for a single environment. Starting in GitLab 13.2, the Terraform Merge Request widget supports multiple Terraform artifact files.
We’re actively looking for feedback about our Terraform features. If you have ideas for improving the Merge Request widget, please share it with us in the Merge Request widget epic.
Opsgenie is a popular IT services management tool for operations tasks, including alerts and incident management. In GitLab 13.2, you can start your Opsgenie workflow directly from within GitLab. Want to give us feedback on this integration? Contribute on this issue and tell us how we can make it better!
Teams maintaining IT services receive hundreds or thousands of alerts a day. GitLab now de-duplicates and organizes your incoming alerts, providing you counts of alerts while keeping your alert list manageable and useful. Your alerts are linked to the incidents created from the alerts, helping you track which alerts have been addressed and which alerts still need to be triaged.
To use a manually configured (external) Prometheus server, it can be problematic to authenticate users from GitLab. In Gitlab 13.2, you can now use OAuth so that authentication is secure and easy to administer.
You can now set variables in your metrics dashboard using PromQL. Your PromQL queries can return a list of values to use as dynamic variables in a metrics dashboard.
GitLab Geo makes distributed teams work more efficiently, creating and maintaining a local copy of GitLab that reduces latency so they don’t have to wait for files to download over long distances. In this update to Geo, we’re improving how the database manages changes. To determine what needs to be replicated from the primary, Geo compares the tracking database to the read-only secondary database. If Geo’s
database queries time out, data can’t be replicated successfully. In
GitLab 13.2, we use a new approach to synchronize Projects, thereby
eliminating the possibility of database statement timeouts. We also
improved the way we remove data from secondary nodes for all data sources, which increases the overall scalability and performance of GitLab Geo.
These iterations bring us closer to removing Geo’s dependency on Foreign Data Wrappers, which were added for improved performance, but which make Geo more complex and harder to maintain.
Geo replicates data from a primary Geo node to one or several Geo
secondary nodes. While Geo supports pausing replication for
repositories and files via the administrator interface, it was
not possible to pause database replication. In 13.2, Geo supports
pausing and resuming replication of all replicated data, including the
PostgreSQL database using the new gitlab-ctl geo:pause and gitlab-ctl geo:resume commands on a secondary Geo node.
This allows systems administrators to pause all replication on a
secondary Geo node while performing critical maintenance operations on
the primary Geo node. In the case of a failure on the primary, no
changes are replicated to the paused secondary node, which can then be
used to failover to.
When performing a failover using GitLab Geo, systems administrators should perform a number of preflight checks using the gitlab-ctl promotion-preflight-checks command.
In GitLab 13.2, the gitlab-ctl promotion-preflight-checks command now automatically checks the replication status and informs you of the results, removing a step that used to be performed manually. The gitlab-ctl promote-to-primary-node command also supports a force mode, which means a failover will proceed even when some preflight checks fail.
The minimum size for compressing NGINX responses has been lowered from 10,240 bytes to 250 bytes. This reduces the number of requests that need more than one packet, and decreases the time it takes to load web pages. For details, see the Merge Request.
The settings to configure object storage have been consolidated so that object storage for all objects can be configured in the same section in gitlab.rb. This is a great improvement that makes object storage configuration much more efficient, including the ability to use a single credential for object storage in multiple S3 buckets. It also enables GitLab Workhorse to upload files directly with its own S3 client, eliminating the need for a pre-signed URL. For more details, refer to the Object Storage documentation.
An Omnibus install package is now available for Ubuntu 20.04.
An Omnibus install package is now available for SLES 12.5.
The version of Chef that is packaged in GitLab has been updated to Chef 15.
Previously, when connecting to Amazon Elasticsearch Service on AWS to enable Advanced Global Search, you could only use static credentials or EC2 IAM roles via Aws::InstanceProfileCredentials.
Now, as an additional authentication option, you can use IAM roles for Amazon ECS tasks.
In GitLab 13.2, we’ve improved the project removal experience to be consistent across all pricing tiers and introduced a group-level toggle to allow you to enable a deletion delay period before permanent removal. Previously, the default behavior for removing a project was different across Tiers. Projects would be immediately removed in the Free/Core and Bronze/Starter Tiers and delayed by 7 days in the Silver/Premium and Gold/Ultimate Tiers.
Now, this behavior is consistent across the board and removing a project will result in the immediate removal of that project. To ensure you still have flexibility in this workflow, we’ve introduced a group-level toggle to “Enable delayed project removal” for groups and projects where preventing data loss is a key requirement. Deleting a project should be easy when it needs to be and have safeguards in place for organizations with stricter requirements around preserving their intellectual property.
Managing user credentials is an important element of any compliance program and requires visibility for the compliance professionals tasked with ensuring policies are being followed. The credentials inventory now highlights any SSH key or Personal Access Token (PAT) which has expired. Additionally, revoked PATs will also be highlighted to provide compliance professionals the necessary insight they need to conduct a review of user credentials.
This change is part of a larger initiative to make credential management within GitLab more simple, friendly, and flexible for customers to implement the processes that make the most sense for their users and organization.
When managing and planning multiple issues, it can be cumbersome to update each issue’s health status separately.
You can now edit the health status of many issues at once from the Issues List.
When sharing, reviewing, or presenting your Roadmap, you often need to minimize some sections or tailor
the information displayed for the right audience. GitLab now allows you to minimize the Milestones
section of the Roadmap to display more epics or hide unnecessary information.
In the 9.1 release, we added Service Desk to our Premium tier, allowing teams to connect directly with external users through email.
Listening to our customers, we learned that Service Desk is a useful feature for teams of any size. In GitLab 13.2 you can now enable Service Desk regardless of your GitLab tier.
Suggesting changes
in merge requests makes proposing improvements easy, but if you receive
many suggestions, applying them one by one is slow.
With Batch Suggestions, you can apply multiple suggestions at once, which is faster and
easier! It’s also beneficial to keep the commit history in a merge request clean and tidy.
Thanks Jesse Hall for your
contribution!
Gitaly Cluster now supports Transport Layer Security (TLS), which means all communication between Gitaly and its clients, GitLab and Praefect, are encrypted when TLS is enabled for both Gitaly and Praefect components. This is helpful when deploying GitLab to a network with other internal services that are not trusted.
Previously, communication between GitLab and Gitaly supported TLS encryption, but encryption was not supported when using Praefect, which is a component of Gitaly Cluster.
Since designing is such a massive part of the product development process, it’s important that the designs you have created and added to issues are easy to find. Before 13.2, we had the Design tab, but we’ve moved designs up, so they are now right under the issue description.
This will encourage more collaboration and ensure that everyone sees the designs right beneath the issue description.
GitLab CI is fast and highly configurable, but it can be hard to remember all the configuration parameters, and the wrong typo can make your .gitlab-ci.yml file invalid. To make it easier to configure your GitLab CI pipeline, the Web IDE now provides real-time linting and completion when editing .gitlab-ci.yml files.
Linting and completion feedback is provided inline in the Web IDE with tooltips to help understand why you’re seeing an error. Currently, this feedback is based on a community-contributed schema from Schemastore, but we are continuing to evaluate a built-in schema as part of GitLab.
Gitaly Cluster allows Git repositories to be replicated on multiple warm Gitaly nodes. This improves fault tolerance by removing single points of failure. However, because write operations are currently replicated asynchronously, the GitLab server only has one copy of the change initially.
In GitLab 13.2, transactional write operations to Git repositories can be enabled for Gitaly Cluster. When this option is enabled and an update is pushed to GitLab, the write operation will be proxied to the replica Gitaly nodes. The write operation will be coordinated between the Gitaly nodes using the two-phase commit protocol, so that they agree on the new state of the repository. Write transactions are currently limited to operations pushed over the HTTP and SSH Git interfaces, and does not include write operations via the GitLab interface like the Web IDE.
In the 9.3 release, GitLab added Code Quality scanning to our Starter/Bronze tier, allowing you to see code quality changes directly in your merge requests. Since then, our users have provided feedback that this data is valuable to teams of any size, including individual contributors. In 13.2, you will be able to see Code Quality reports in your Merge Requests regardless of your GitLab tier.
With the new exclude syntax, you can prevent specific files from being added to artifacts. This eliminates the need to explicitly reference the path of every folder that should be added to the artifact (to avoid including too much). Support for wildcards (globs and double star globs) makes it easy to exclude entire subdirectories.
If you add a merge request to a Merge Train, but the system removes it due to an issue, you now receive a notification in the form of a To-Do task. This means you can add an MR to a Merge Train with confidence, knowing that either a merge will happen automatically, or you will receive a notification of failure. If the merge is unsuccessful, you can quickly correct errors and resubmit your MR instead of being surprised later to learn it was never merged.
If you’ve looked at a complex pipeline graph wishing there was an easy way to know which job triggered a specific downstream pipeline, then wish no more. Now you can simply hover over a downstream pipeline to see a tooltip that names the job which triggered the pipeline. And there’s no need to skim all the job names to find “the one” because the hover action also highlights the trigger job in the upstream pipeline.
Historically, the environment:action keyword did not accurately represent environment jobs that didn’t result in a deployment, such as in-approval jobs and building images for future deployments. In GitLab 13.2, jobs now contain a prepare keyword to make the state of non-deployment environment jobs clearer, keeping them accurate and representative of your deployment activities.
GitLab users without Maintainer access currently cannot interact with Terraform commands, including terraform plan, which creates an execution plan useful in development workflows. In GitLab 13.2, users with the Developer role gain read-only access to the Terraform state API, enabling more users to contribute without risking improper usage.
When you change the status of an alert, assign it to a team member, or create an issue from the alert, GitLab tracks these events and displays them as notes on alert detail pages. Notes provide helpful context to responders, enabling your team to better collaborate when triaging alerts, and preventing unnecessary duplication of work.
You can now use keyboard shortcuts to interact with your metrics dashboards in GitLab 13.2. With keyboard shortcuts, you can quickly navigate through a dashboard while triaging an incident, speeding up the response workflow.
Alerts are often noisy and plentiful. To help you find relevant alerts you need to triage, and refine the list of displayed alerts, you can now conduct plain-text searches in the Alerts list.
After you configure your alerting systems to route alerts to your GitLab REST endpoint, you can now trigger test alerts to ensure you’ve configured your systems properly, giving you extra peace of mind.
We want to help developers write better code and worry less about common security mistakes. Static Application Security Testing (SAST) helps prevent security vulnerabilities by allowing developers to easily identify common security issues as code is being contributed and to mitigate proactively. As part of our community stewardship commitment we are making our JavaScript & TypeScript SAST analyzer (ESLint) available in every GitLab tier. This will allow ALL GitLab users developing in JavaScript or TypeScript to leverage SAST security Scans for their projects.
As part of this move, we have deprecated our existing TSLint Analyzer, as its functionality is now present in ESLint. You can learn more about this in our deprecation notice.
We will continue to move other open source (OSS) SAST analyzers to Core. You can follow our SAST to Core epic to see when other analyzers will become available, and even contribute to this effort.
Systems administrators can adjust Geo settings for individual nodes using
the administrator interface. Until now, these forms contained some
outdated user interface elements, displayed too much optional
information, and some inputs were not properly validated.
In GitLab 13.2, the individual Geo node
settings and
general Geo
settings validate
user input and are divided into different sections (for example,
“Performance and resource management”) to make it easier for systems
administrators to find related settings.
Geo now supports replicating Package Registries to
secondary nodes, allowing distributed teams to access them from
the closest Geo node, which reduces latency and improves the overall user experience.
Additionally, the Package Registry assets can also be restored from a secondary node when
failing over to that node.
Kubernetes 1.13 is now the minimum supported version. Support for Kubernetes 1.12 was dropped in this release. For more details, see the removal notice.
For self-managed GitLab installations, Patroni is now available as an alternative PostgreSQL replication and failover solution. Patroni brings improvements over repmgr, which it replaces. With Patroni, a failed primary is automatically added back to the cluster as a standby node when it comes back online. The addition of Patroni also unblocks us from adding support for PostgreSQL 12, and supporting PostgreSQL replication and failover on a Geo secondary site. Use of Patroni with Geo is currently being tested and is not yet supported. This switch supports GitLab’s goals to dogfood our solutions. Gitlab.com has been using Patroni to manage failover since 2018, making it a well tested solution. Repmgr will continue to be available in Omnibus GitLab until GitLab 14.0. For instructions on setting up Patroni, which is currently experimental, see GitLab’s Patroni documentation.
With the previous version of Advanced Global Search, if you needed to reindex, you would have to plan for Advanced Global Search to be down. Search results were unavailable while the index was deleted and the new index created.
In 13.2, we have added index aliases that allow you to reindex without any downtime with a press of a button in the admin settings. Going forward Advanced Global Search can be reindexed without disrupting any of your users’ workflow! This is important, because on larger instances it can take some time for the reindex to complete.
In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!
In GitLab 13.2, we’re shipping performance improvements for issues, projects, milestones, and much more! Some performance improvements in GitLab 13.2 are:
The next time the SAST job runs after this transition you may see previously present TSLint vulnerabilities being marked as “resolved” and new TypeScript vulnerabilities from ESLint. This behavior is expected due to the new unique vulnerability signatures from ESLint which are different from old TSLint job scan vulnerability signatures.
This transition will be backward incompatible though we expect limited impact. If you use a before_script to pre-build dependencies for your Python project, you should test this change before upgrading to GitLab 13.4. We will add a new section in the SAST troubleshooting documentation with more information about this change as we approach 13.4.
GitLab 13.2.0 remediates an email verification bypass. After upgrading, if some of your users are unexpectedly encountering 404 or 422 errors when signing in, or “blocked” messages when using the command line, their accounts may have been un-confirmed. In that case, please ask them to check their email for a re-confirmation link.
GitLab installations that have multiple web application nodes must be upgraded to 13.1 before they can be upgraded to 13.2. This is due to a breaking change in Rails that can result in authorization issues if this upgrade path is not followed. For details, see this issue. For information about upgrading, see the version-specific upgrade instructions.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback