GitLab 14.2 released with the Build Cloud for macOS beta and Markdown preview
Key improvements in Gitlab 14.2 include the introduction of the Build Cloud for macOS beta, Markdown preview, expanded Gitpod integration, new DevOps adoption metrics, and much more
Cornelius added support
for opening code changes directly in Gitpod when viewing a merge request. In fact, this
release blog post was created and edited with Gitpod! Cornelius initially helped add an
option to open a project in Gitpod to the repository overview page in GitLab 13.5.
That capability has now expanded so that you can launch Gitpod directly from the merge
request page to speed up your reviews and reduce the need for context switching in your
local development environment.
Read the full release post below for more details. Thanks for your contributions
Cornelius! We believe cloud development environments like Gitpod reduce barriers and make
it easier for everyone to contribute.
Today, Apple ecosystem developers on GitLab SaaS need to install, manage, and operate GitLab Runner on their own macOS systems to execute CI/CD workflows.
Now, you can build applications on the new Build Cloud beta for macOS, a GitLab Runner-powered build platform integrated with GitLab SaaS CI/CD.
Access to the beta is initially limited to approved customers and open source community program members. For details, check out this blog post.
The Gitpod integration, introduced in GitLab 13.5, helps you manage your complicated development environments. Once you define your project’s configuration in code, you can launch a prebuilt, cloud-based development environment with a single click. This convenient workflow has made it faster than ever to generate new changes, but launching a Gitpod environment to review an existing merge request meant building an environment against the main branch before switching to the target branch and building again.
Now, in GitLab 14.2, you can launch Gitpod directly from the merge request page, preconfigured to use the target branch, to speed up your reviews and reduce the need for context switching. Enable the Gitpod integration, and your merge requests display a grouped Open in button, so you can open the merge request in either the Web IDE or Gitpod.
Track which groups across your organization have enabled dependency scanning and fuzz testing. Previously, you could only track adoption of these GitLab features through the API.
Now you can compare adoption across your groups from the DevOps Adoption table in the UI and sort the table to easily find which groups are using these security features.
Markdown is a fast and intuitive syntax for writing rich web content. Until it isn’t. Luckily, it’s easy to preview the rendered output of Markdown to ensure the accuracy of your markup from the Preview tab. Unfortunately, the context switch required to move between the raw source code and the preview can be tedious and disruptive to your flow.
Now, in both the Web IDE and single file editor, Markdown files have a new live preview option available. Right-click the editor and select Preview Markdown or use Command/Control + Shift + P to toggle a split-screen live preview of your Markdown content. The preview refreshes as you type, so you can be confident that your markup is valid and will render as you intended.
You can now use variables as part of include statements in .gitlab-ci.yml files. These variables can
be instance, group, or project CI/CD variables.
This improvement provides you with more flexibility to define pipelines. You can copy the same .gitlab-ci.yml file to multiple projects and use variables to alter its behavior. This allows for less duplication in the .gitlab-ci.yml file and reduces the need for complicated per-project configuration.
Over the course of a project’s life cycle, code is moved around. Refactoring, additions to the code base, removals, will all happen. Our current fingerprinting of findings is too coarse and results in a lot of duplicated findings over time as code is moved around. SAST and Secret Detection findings currently use location within a file to declare where they exist within a codebase. Over time we lose the ability to track the movement of a finding as lines are added to, or removed from the file above the finding in question. This reality makes it hard to discern findings that are truly new, especially in the context of a merge request.
We’ve developed a new vulnerability tracking algorithm that is more advanced and looks at the signature of a vulnerability rather than just its location. This new tracking improves the accuracy of identifying the same vulnerability that has moved locations due to code refactoring.
We’ve now brought this new vulnerability tracking system to our GoSec (Go) analyzer, Semgrep (JavaScript, TypeScript, React, and Python), and Brakeman (Ruby and Ruby on Rails) analyzers. We will continue expanding coverage of this new vulnerability tracking system to other language analyzers in future releases.
Using the needs keyword in your pipeline configuration helps to reduce cycle times by ignoring stage ordering and running jobs without waiting for others to complete. Previously, needs could only be used between jobs on different stages.
In this release, we’ve removed this limitation so you can define a needs relationship between any job you want. As a result, you can now create a complete CI/CD pipeline without using stages by including needs in every job to implicitly configure the execution order. This lets you define a less verbose pipeline that takes less time to create and can run even faster.
The GitLab Agent for Kubernetes allows a secure bi-directional connection between GitLab and any Kubernetes cluster.
Until now, registering a new Kubernetes Agent required writing GraphQL queries.
As of GitLab 14.2, GitLab ships with a user-friendly user interface and a registration form to help you get started with the Kubernetes Agent with ease.
Users of the GitLab.com for Jira Cloud application can now create GitLab branches directly from a Jira issue’s development panel. This enables developers to begin work on issues without having to switch tools and lose context.
You can now export a report that lists all members in a given group. This was already possible at the instance level and
we are very excited to bring it to the top-level group!
This report contains information such as users, email addresses, and permissions levels, all describing the users who have access to the group.
This report allows you to quickly get visibility into who is in a group,
and what type of access is possible for your groups
and projects, enabling you to rapidly identify required
updates. This is a great step toward bringing a similar,
high-quality experience to our GitLab.com users, in what was
previously only available on self-managed GitLab.
The new GitLab Migration feature can now migrate an entire group with all its subgroups and related data. The data migrated includes everything contained in group exports, making this a much easier way to migrate entire groups.
The pre-existing group import/export is a two-step process that requires exporting a file and then importing it into another GitLab instance.
Now, users can initiate a group migration with a single click. Migration also includes all the subgroups and their data, which previously required separate export and import processes for each subgroup.
In a previous release, we added a new banned user state. In this release, we now also hide all issues created by a banned user. This is extremely helpful in cases where a malicious user bombards GitLab instances with spam issues. These can now be hidden.
Before GitLab 14.2, the CI pipeline minutes usage on the Usage Quotas page only showed the current month’s usage. This data would reset every month and there was no way to view activity from the past months for analyzing historical usage.
Now there are two charts that show historical CI pipeline minutes usage by month or by project, so you can make informed decisions about your pipeline usage.
Compliance framework labels are now shown on the group-level project list. This allows you to
identify at a glance which projects have specific compliance frameworks applied.
You can now set a compliance framework for projects using the GraphQL API
in addition to the GitLab UI.
This makes it easy to do bulk updates to many projects at once and supports those who
prefer to create and configure projects programmatically.
Customers with Rails console access can create group access tokens to perform actions at the
group level, and manage projects in the group with a single token. Previously, using a group
access token for Git credentials caused an authentication failure. In this release, we’ve:
Added support for group access tokens to authenticate with Git over HTTP, making it
possible to push and pull changes with a group token.
You can now more easily see the volume of work in each stage. Value Stream Analytics for projects now shows the total number of workflow items in each stage of a value stream.
Until now, project and group-level metrics in value stream management displayed different data sets.
In this release, you can view the same metrics on the project and group level, based on your GitLab subscription. Both project and group analytics now include New Issues, Commits, Deploys, Deployment Frequency, Lead Time (Premium and Ultimate), and Cycle Time (Premium and Ultimate).
Editing an issue in an issue board currently requires many steps and takes you out of your workflow. We’ve added an easy way to edit an issue’s title right in the issue board, without navigating to another page. To edit the title, in the right sidebar, select the issue, then select Edit.
The new WYSIWYG editor has made writing Markdown in your wiki easier than ever. However, the toolbar’s position in the editor made formatting text on longer pages tedious and repetitive.
In GitLab 14.2, the most frequently used formatting options (bold, italic, strikethrough, and code) display in a floating menu above your text selection. By limiting the distance you have to move your cursor while formatting, you can work more efficiently. Spend more time focusing on your content, and less on scrolling up and down the page.
We’re also releasing GitLab Runner 14.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.
The pipeline IID gives the internal ID of a pipeline relative to the project that triggered it, and it increments for every new pipeline in the project. The pipeline IID increments much slower than the pipeline ID, which increments by one for every pipeline in the whole GitLab instance. This makes the pipeline IID a more useful value for use cases like versioning project releases based on pipelines, tracking pipelines based on their run order in the project, project pipeline metrics, etc.
To help improve the experience of using the pipeline IID, we are adding an option to the pipelines page to change the display from the ID, to the internal project IID. Now you can easily see which pipeline matches the IIDs you are using.
To reduce your reliance on external dependencies and reduce build times, you can use the GitLab Dependency Proxy to cache frequently used images from Docker Hub.
You can now use deploy tokens when authenticating to use the GitLab Dependency Proxy. Previously, you had to authenticate with predefined environment variables. Such variables are tied to a user’s permissions and therefore not ideal for production pipelines. Deploy tokens are easier to manage for authentication. With deploy tokens, you don’t have to worry about adding someone to your project. You can create a token, set the desired scope, and then rotate users according to your organization’s policies.
Simply create a group deploy token and user name with the scope set to read_registry and write_registry. Then you can login to the GitLab.com registry with your deploy token username and password, and proxy and cache container images from Docker Hub.
In GitLab 13.10, we introduced the concept of deployment tier. In this release, we added deployment_tier in the Pipeline events webhook so that you can use it in your automations.
You can now update the incident issue’s severity with the /severity quick action. For example, using the /severity 3 quick action in an incident issue sets the severity to 3. This handy keyboard shortcut enables incident responders to quickly update the incident and get right back to resolving the problem.
GitLab has greatly expanded Security and Compliance functionality
over the last year. As features have grown, so have the number of related configuration
options. The current Security & Compliance Configuration page has expanded beyond
what it was originally designed to accommodate, making finding the right option
cumbersome.
To address this, we have redesigned the Security & Compliance
Configuration page. Not only does the new design improve usability, it provides a
flexible pattern that will scale as we continue to add to our security and compliance
offerings.
We have updated our Static Application Security Testing (SAST) Go analyzer, GoSec, to support Go 1.16. This update introduces support for Go projects requiring this version of Go but also limits GOPATH shimming to only projects without Go modules.
Should you require GOPATH shimming you can now pin to a minor version of an analyzer using GoSec version 3.1.3. Pinning to a previous version will prevent you from receiving automatic analyzer updates and require you to manually bump your analyzer version in your CI template.
GitLab Static Analysis is comprised of a set of many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. Below are the analyzer updates released during 14.2. These updates bring additional coverage, bug fixes, and improvements.
Want to remain on a specific version of any analyzer, you can now pin to a minor version of an analyzer. Pinning to a previous version will prevent you from receiving automatic analyzer updates and require you to manually bump your analyzer version in your CI/CD template.
Users often want to search for files and then open them in their editor of choice. In GitLab 14.2, we added a file path copy icon beside the file path of the search results. Users can click the icon to copy the file path and paste it to their editors to open the file.
Sometimes when searching broadly across GitLab, timeouts can occur. We implemented a search timeout page to help users in these situations and take advantage of stronger search criteria.
You can now add pronunciation to your user profile. In distributed teams where team members are from different countries, it can be difficult to determine how to say someone’s name correctly. This will help others know how to pronounce your name.
Local time is now displayed on user profiles. In previous releases, you could set the timezone but it was not visible throughout GitLab. This improvement is extremely helpful for distributed teams to help others know when others are likely to be available.
Previously, the Secret field was visible in the GitLab UI on an application’s configuration page. To improve security, we have hidden this field from the UI and added a Copy button. You can then copy the secret and store it in a secured location. This makes sure the secret is not visible in clear text for anyone looking at the screen.
Users can now see which labels they used to filter their Jira issues list. This change improves usability by allowing users to have full context of the list they are viewing.
In this release, we are making the management of project integration configuration much easier! GitLab administrators can now see a list of projects that are not using the default integration configuration. This functionality helps administrators ensure that projects have the right data from integrated systems.
Delayed project removal protects your data by placing deleted projects in a read-only state so you can restore them. Until now, delayed project deletion has been disabled on GitLab.com because there has been no way to immediately delete a project when necessary.
In this release, we’ve added an instance setting to enable delayed deletion by default for all new projects. You can also immediately permanently delete projects that are scheduled for delayed deletion without globally disabling the setting.
Delayed project deletion is now enabled by default for new groups and projects created on GitLab.com, and group owners can disable it.
GitLab 14.1 introduced the ability to upload and insert images into the new wiki content editor.
Now in GitLab 14.2, you can upload and attach .zip, .pdf, .txt, and other binary files in the same way. This brings us one step closer to feature parity with the classic wiki editor, and unlocks additional ways for you to collaborate on rich content in your wiki pages.
The pipeline mini graph shows you the status of each stage in your pipeline and gives you a quick and easy way to navigate to any job. Linking multiple pipeline mini graphs together provides you with the same functionality for related upstream and downstream pipelines.
In this release, you have the ability to see linked upstream and downstream pipelines in the mini graph in new areas in the GitLab UI: the pipeline tab, the project pipeline page, the commit page, and the commit page’s pipeline tab.
When you are configuring your project, you can control feature-specific permissions for things like issues or the repository. For example, in a public project, you can still limit repository access to project members only.
The problem is that although you can control several features like this, for the container registry, you only had the ability to toggle the feature on and off. This is problematic for many organizations that would like to control access to the container registry separately from the repository.
Now you can avoid that problem by configuring your project to define an access level for your container registry independent of the access level of your repository and other features. You can do this using the project’s API and the user interface.
Until now, users of the GitLab Agent for Kubernetes CI/CD Tunnel had to add
a corresponding kubeconfig configuration file to a CI/CD job manually. Creating the
kubeconfig file required editing the CI/CD pipeline definition, a knowledge of the Agent
ID, and an understanding of how a kubeconfig is structured. It also introduced
boilerplate code into the CI/CD pipeline definition.
GitLab now injects a kubeconfig file that contains all the available agent connections for
the given project. A user only has to choose the right kubecontext to use.
The GitLab managed Terraform state can be accessed from GitLab
CI/CD without any special configuration. To access the same state from a local
machine, Terraform must be initialized with several parameters.
Finding the right parameters can be a tedious and error-prone process, so we now provide a
simple user interface on the Terraform State list page
that shows the command to use to initialize a Terraform state access from the command
line. You can access this view from the Infrastructure > Terraform menu.
When creating the escalation policy for alerts, it’s useful to email a specific user in addition to the on-call user. In this release, we added the ability for teams to define the user to contact, even if that user isn’t part of the on-call rotation.
We have updated our Static Application Security Testing (SAST) for .NET, Security Code Scan, to migrate to a new Alpine base image for this analyzer for consistency as well as improved stability, performance, and security. This generally should not cause problems, however if you leverage before_script with the security-code-scan-sast job, you may need to update your before_script to resolve any incompatible function calls.
We’ve also updated Security Code Scan to its latest major version (v5). This adds support for projects built with Visual Studio 2019 and is a major upgrade to a new inter-procedural taint analysis engine. Due to the major upgrade, we are making this opt-in for now and a future release will update this version by default. To begin using this updated version, please leverage the following override to pin Security Code Scan to the new version: SAST_ANALYZER_IMAGE_TAG: 3.
In future versions of GitLab, we will update the default version of Security Code Scan to this new version, at which point you will no longer need to use the above code snippet.
In GitLab 13.12 we released Semgrep for Javascript, TypeScript, and Python. Today we’re expanding the Semgrep analyzer to support projects written in the C language.
Developed in partnership with r2c, the team behind Semgrep who share our mission to help developers write more secure code. After an extensive beta with hundreds of customers trying out our experimental analyzer, we’re ready to start the transition to Semgrep.
With 14.2, we’re updating our managed ‘SAST.gitlab-ci.yml’ CI template to automatically run this new analyzer alongside our existing C/C++ analyzer, Flawfinder. In a future release, we will fully disable Flawfinder once we add support for C++, but for now it will work in unison with Semgrep. We’ve done work to deduplicate findings, so you should not notice any difference in findings. If you include our ‘SAST.gitlab-ci.yml’, you don’t need to do anything to start benefiting from the Semgrep analyzer. However if you override or manage your own SAST CI configuration, you should update your CI configuration.
We are excited about the future of this transition to bring you fast and wide coverage Static Application Security Testing (SAST). We’ll continue to expand the Semgrep analyzer through new security detection rules as well as expanding coverage to other languages. We’ve created a feedback issue where you can share your experience with this transition or ask questions.
Geo automatically verifies the data integrity of replicated versioned snippets. This ensures that snippets are not corrupted in the transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects customers against data loss.
In the next iteration, we will implement automatic healing once a mismatch in verification is detected.
Note: This feature was originally announced by mistake in the GitLab 13.11 release post. It was available behind a feature flag, but not enabled by default. In GitLab 14.2, we removed the feature flag and enabled versioned snippet verification.
GitLab 14.2 includes Mattermost 5.37, an open source Slack-alternative whose newest release includes a new beta feature, Collapsed Reply Threads. Users may experience bugs, and current known issues are documented. Additionally v5.37 includes support for emoji standard v13.0. If you have added a custom emoji in the past that uses one of the new system names, then it is going to get overwritten by the system emoji. The workaround is to change the custom emoji name. Also, parts of Incident Collaboration are now available to all Mattermost editions. As part of this update, Incident Collaboration will require a minimum server version of v5.37.
GitLab 14.2 supports two new features for more secure Patroni patterns. This includes support of TLS for the Patroni API, allowing users to use TLS for a more secure communication. GitLab 14.2 also includes support for allowlist and allowlist_include_members with Patroni. This allows users to limit write access to the Patroni REST API by IP address, a further protection in addition to the authentication measures.
Sidekiq, the job scheduler used by GitLab, creates a number of read-only jobs. When using a database cluster that includes a read and writable primary node and one or many read-only nodes, these jobs do not have to be executed on the primary node. Instead, they can benefit from database load balancing and execute on read-only nodes. This reduces the overall load on the primary database node and can result in performance improvements.
Sidekiq load balancing was introduced in GitLab 14.1 and is enabled by default in GitLab 14.2.
In every release, we continue to make great strides improving the performance of GitLab. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!
In GitLab 14.2, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 14.2 are:
In every release, we make great strides in improving the overall effectiveness and usefulness of our product.
We also have a UI Polish Gallery to track important updates to our interfaces. These updates, while often small, improve your user experience.
Some of the notable usability improvements in GitLab 14.2 are:
GitLab 14.2 contains long running background migrations that swap columns on tables potentially affected by primary key overflows. Read the GitLab 14.2 update instructions for further guidance and to learn what tables are affected.
Before upgrading to GitLab 14.2, you must upgrade to either the latest patch release of GitLab 14 (14.0.Z) or the latest patch release of GitLab 14.1 (14.1.Z). This is important because these releases contain batched background migrations as part of our ongoing effort to address primary key event overflow risks. These background migrations included in the specified prior releases have to finish before upgrading to GitLab 14.2. Read the GitLab 14.2 update instructions for further guidance.
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