GitLab 14.1 released with Helm Chart Registry and Escalation Policies
GitLab 14.1 released with the ability to build, publish, and share Helm charts, create escalation policies to page responders, connect GitLab Runners to your Kubernetes clusters, enforce code coverage decisions, and much more!
Andrew actively contributed numerous merge requests in the GitLab 14.1 release to help improve GitLab’s planning capabilities. He was able to make some significant improvements to GitLab’s issue and epic boards. Thanks to his work, GitLab users are now able to sort epic lists by title; view the number of open issues, weight, and progress in epic boards; and view milestone weights on milestone view lists.
In addition to contributing to the product in key ways, Andrew collaborated closely with the team as he helped identify and fix all the bugs and barriers he encountered along the way.
Thank you Andrew for helping to make GitLab better! 🙌
Helm defines a chart as a Helm package that contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. For organizations that create and manage their own Helm charts, it’s important to have a central repository to collect and share them.
GitLab already supports a variety of other package manager formats. Why not also support Helm? That’s what community member and MVP from the 14.0 milestoneMathieu Parent asked several months ago before breaking ground on the new GitLab Helm chart registry. The collaboration between the community and GitLab is part of our dual flywheel strategy and one of the reasons I love working at GitLab. Chapeau Mathieu!
Now you can use your GitLab project to publish and share packaged Helm charts. Simply add your project as a remote, authenticating with a personal access, deploy, or CI/CD job token. Once that’s done you can use the Helm client or GitLab CI/CD to manage your Helm charts. You can also download the charts using the API or the user interface.
Being on-call is a stressful, 24/7 job. It’s possible to miss a notification despite your best efforts and intentions. Teams that maintain critical systems can’t afford to miss alerts for outages or service disruptions. Escalation policies are a safety net for these situations. Escalation policies contain time-boxed steps that automatically page a responder in the next escalation step if the responder in the step before didn’t respond. To protect your company from missed critical alerts, create an escalation policy in the GitLab project where you manage on-call schedules.
In GitLab 14.1, users can create, view, or delete escalation policies.
Until now, connecting Kubernetes clusters to GitLab CI/CD required users to open up their clusters towards GitLab. Some organizations do not encourage opening up their firewall externally due to security concerns.
GitLab now ships with a CI/CD Tunnel that connects GitLab Runners with your Kubernetes cluster using the GitLab Agent. This enables versatile GitOps workflows where the deployment logic can be coded in the pipeline.
You and your team can safely use your preferred tool to run the deployment itself using kubectl, helm, kpt, tanka, or anything else without security concerns.
To use the tunnel, define the kubecontext in your CI/CD pipeline to connect with your agent. To simplify this process, we plan to automatically inject the kubecontext into the CI/CD environment in a future iteration.
The CI/CD tunnel is currently supported only from the project where the agent was configured but we are working on adding group-level support. You can safely start using the tunnel on GitLab SaaS and self-managed instances.
To keep code test coverage high, you need to ensure that merge requests to your codebase never decrease test coverage. Previously, the only way to enforce this was to require approvals from users who would check for test coverage decreases as part of their reviews.
Now you can enforce this organizational policy with the new Coverage check approval rule. This is a simple way to ensure merge requests that would decrease test coverage cannot be merged.
The integration with Datadog Continuous Integration Visibility provides detailed breakdowns of your GitLab pipelines, unit tests, and integration tests. View high-level metrics over time: execution statuses, durations, percentiles (p50 and p95), failure rates, queue times, and more. Datadog dashboards help you sift through your GitLab CI/CD data to identify problematic jobs that cause pipelines to fail most often.
We began improving your wiki editing experience in GitLab 14.0, when we introduced the MVC of a new WYSIWYG Markdown editor. It supported the most common Markdown formatting options, but with some notable gaps. GitLab 14.1 continues to improve your editing experience for images and tables. You can now upload images directly into the editor. You can also insert and edit tables, including copying and pasting content from popular spreadsheet applications to bring tables from other sources into your wiki.
Users can now specify the level of access that a project token should have on the project level upon creation and can view existing project access token roles.
Prior to this release, project access tokens had the Maintainer role. For some users, this role included elevated permissions that were not required.
To avoid abuse, this feature is available for all users except for free GitLab SaaS accounts. All self-managed users as well as Premium and Gold SaaS customers can now easily select and view the appropriate role for their project access tokens.
You can now contact an external API to perform a status check in a merge request. This is a great way to integrate GitLab with third-party systems that:
Run in an external system and do not have specific pipeline jobs.
Require manual approval in another system.
In the project, APIs for the status checks can be configured (using either the GitLab UI or the GitLab API) and then when a change is made to a merge request, that API is called with various details about the merge request. The external API can then respond with a return code to indicate if the check has passed. This result is then shown in the merge request.
This allows teams to easily stay in sync and makes it easy to see that merge requests have met external requirements before being merged, adding an extra method to ensure compliance requirements are met.
We have introduced a new quick access view to the Compliance Dashboard for you to review merge requests.
Clicking on a merge request in the list will open the view. This makes it easy to quickly
see the status and the details of merge requests, directly inside
the Compliance Dashboard.
This helps save time by showing information about each merge request, such as the author, title, approvers,
commenters, and more. You no longer have to open each merge request individually
to see that information. Compliance teams can quickly review the full list of merge requests and find the ones that need attention, rather than spending time reviewing ones that do not.
You can now require that all merge requests in a project have an associated Jira issue created. This is a great way to ensure that code changes in GitLab are reflected in Jira issues and that teams can better stay in sync.
GitLab’s Dynamic Application Security Testing (DAST) now supports a new guided configuration experience. We believe that security is a team effort and this configuration experience makes it easier for non-CI experts to get started with GitLab DAST. The tool helps a user create a merge request to enable DAST scanning while leveraging best configuration practices like using the GitLab-managed DAST.gitlab-ci.yml template and properly overriding template settings.
With GitLab DAST, users often create multiple configurations to cover different areas of their application. The new DAST configuration UI lets users create DAST site and scanner profiles. Those profiles can then be referenced in CI/CD pipeline jobs. The configuration is stored in the database and is referenced at scan runtime to load the configuration variables into the job. The only required YAML configuration is specifying the names of the site and scanner profiles that you want to use in your scan. This makes it incredibly simple to switch out configurations when your application requires. Building YAML config files for DAST from scratch is no longer necessary for your DAST jobs. We can build them for you.
If you’re a developer authoring or reviewing a merge request, you want to know how every change
impacts the quality of a project. To do this within GitLab, you previously needed
two windows open:
On the code diff of the merge request.
On the main merge request page to see the code quality changes.
This back-and-forth is inefficient, and makes it easy to miss critical code quality issues.
The merge request Changes tab now shows you which line introduced a code quality violation, and its severity, so you can quickly identify the most critical issues to resolve. Hovering over the icon provides details about the violation.
Audit events are now created if a GPG key or SSH key is created using the API. This extends visibility beyond users that create keys using the GitLab UI to help you understand and secure all the ways GitLab could be accessed.
Audit events are now being created when the compliance framework for a project is changed. This provides greater visibility into potential abuse of policy controls of your projects.
The new GitLab Group Migration feature now includes Epics with all the relevant information, such as labels, comments, events, and award emojis. Existing users are matched and assigned to the Epics. The addition of Epics is a significant step in delivering a better alternative to the file-based Group Export/Import feature.
When you import from GitHub, the logs now contain the counts of all imported objects. This information helps users validate their imported data and troubleshoot any import issues.
See the total number of key DevOps features adopted across your organization using the new progress bars in DevOps Adoption. Progress bars help you understand the value that teams are getting from GitLab and evaluate the state of your DevOps transformation.
GitLab displays relative times (for example, 30 minutes ago) in a lot of places. You can now change your user profile preferences to display absolute times instead, for example, ‘May 18, 2021, 3:57 PM’.
Absolute times respect your browser settings and format dates and times based on your preferred locales, for example, British English over US English. This new display option gives more information at a glance for users that need it for workflows like correlating actions in GitLab to external systems.
When responding to feedback on a merge request in Visual Studio Code, it wasn’t easy to know which files had comments. You had to open each file and search for comments.
With GitLab Workflowv3.24.0 for VS Code, we now indicate which files have comments in the merge request. This helps you easily identify the files you may need to review, to address their comments.
As part of the larger effort to rename Git’s default initial branch in a GitLab project from master to main, we are adding an automatic redirect to streamline the transition. Previously, when projects renamed the default branch, current URLs would result in 404 Not Found. This is a frustrating experience when you are trying to navigate between branches. Now, if you navigate to a file or directory path whose default branch was renamed, you will be redirected to the updated path automatically.
Linking directly to a single, highlighted line of code or text supports collaboration on a single line, but discussions often address multiple lines of code or text. Some code editor plugins, such as GitLink for JetBrains IDEs, generate an anchor link from a selected range over multiple lines. Previously, you couldn’t use such links in GitLab repositories, because GitLab and GitHub have incompatible formats for anchor links highlighting multiple lines. Previously, only manually modifying the incompatible URL in GitLab enabled highlighting multiple lines. GitLab now supports both GitLab and GitHub formats for code highlight anchor links that cover multiple lines.
Templates provide an easy way for you to get familiar with GitLab CI/CD. We have a large number of templates, but accessing them isn’t intuitive. In this release we’ve added a way for you to navigate directly to the template library from the pipeline editor. This makes it easy to browse through the different templates GitLab has available, so you can more easily copy and paste the relevant sections directly into your pipeline configuration.
We’re also releasing GitLab Runner 14.1 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 instance-level runner registration token is sensitive information. If someone were to “shoulder surf” a GitLab administrator, they could copy the instance-level registration token and use it to add unauthorized runners and read secrets from the GitLab instance when runners process jobs. We have masked the token so it is only left visible on the screen when intended.
It was really challenging to get a complete picture of your CI minute consumption because public projects were excluded from quotas. As a result, we have improved the pipeline usage page to show public project CI minute consumption. Including public projects in the CI minute quota enables you to get a complete picture of your usage to make informed decisions about your pipeline efficiency. These quotas are also supporting our efforts to curtail crypto-mining abuse.
Additionally, we are starting to implement quotas for the use of our public shared runners by pipelines in public projects. Initially, quotas for public projects will apply to all new namespaces created after July 17th. All plans will have a quota, and for new users on the Free plan, public projects will have 50,000 minutes of shared runner use available for their jobs.
You can use the GitLab Package Registry to publish and install NuGet packages right alongside your source code and pipelines. Since packages are collections of code, sometimes they have bugs. So how do you debug NuGet? One common way is to use debug symbols that provide information like the association between compiled and source code, names of local variables, stack traces, and more.
The problem is that although GitLab supports NuGet packages, until recently symbol packages (.snupkg) weren’t supported. This made it more difficult to share these important debugging packages with the rest of your team and prevented you from relying on GitLab as the single source of truth for your NuGet packages.
GitLab now supports publishing and installing symbol packages. To publish a symbol package, simply run nuget push My.Package.snupkg -Source <source_name>. Then you can download the .snupkg files by using the API or the user interface.
In GitLab 14.1, we are fixing the create/edit/delete release permissions to match tag creation permissions so that users have a consistent experience. This bug fix is highlighted individually because for projects that have releases associated with a protected tag, the user must have write access to both releases and protected tags in order to access the release. If this bug fix affects you, add the pertinent user to the Allowed to create list in the protected tag setting.
Vault users can easily retrieve secrets from within GitLab CI/CD by using the GitLab Vault integration. The integration initially created file type secret variables, and this approach had a few shortcomings. To overcome these we are introducing a new boolean file keyword where you can specify if the returned variable should be stored as a plain environment variable or a file.
This feature requires a GitLab Runner version 14.1.0. For backward compatibility, the default is to store the variables as file types (file: true).
As a part of our project to move to a browser-based DAST ecosystem, we have switched the DAST authentication method over to using browser-based authentication. In addition to supporting all of the existing DAST methods of authentication, this new system allows for advanced debugging by generating a report that contains screenshots and HTTP requests made during the authentication process. The report allows a user to view all the steps in the process and see what is happening if authentication fails. The new authentication method also contains quality-of-life improvements such as greater flexibility for how to select login form elements on a page, support for clicking elements to show a popup login modal, strategies for validating whether or not authentication succeeded, and direct access to the browser logs for debugging purposes.
You can now enable Dependency Scanning for your Java 16 Gradle projects. Set the DS_JAVA_VERSION environment variable to 16 to use this enhancement. In addition the gemnasium-gradle-plugin has been updated to support Gradle 7.0. Gradle 7.0 issue.
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.1. These updates bring additional coverage, bug fixes, and improvements.
Flawfinder updated to version 2.0.18 - MR, Changelog.
Removes support for Python 3.8 to mitigate security issue.
If you are including the GitLab managed vendored SAST template (SAST.gitlab-ci.yml) you do not need to do anything to receive these updates. However, if you override or customize your own CI/CD template, you will need to update your CI/CD configurations. If you 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.
GitLab 14.1 replaces tail/xtail in favor of GitLab Logger in Gitaly cloud native GitLab Containers. In the past, logs were less structured which made it potentially more challenging to do proper analysis. Using GitLab Logger allows better tagging of logs to improve forensic analysis.
Registration Features introduces the ability for free, self-managed users running GitLab EE to access paid features by registering with GitLab and sharing activity data via Service Ping. Features introduced here do not remove the feature from it’s paid tier, or prevent users from accessing at that tier without sharing usage data. The first feature introduced is email from GitLab, enabling instance administrators to email users within their instance.
Audit events are now created if a user is added as an administrator for the GitLab instance. This helps ensure that if anyone becomes an administrator (meaning they make changes to instances), there is a record of their permissions being elevated that can be audited later.
Users are now shown a warning if they choose to synchronize their groups with LDAP. Once groups are synchronized with LDAP, all users that are external to the LDAP group lose their access. This ensures that the user is aware of the impact of synchronization and gets a confirmation before the synchronization takes place.
You can now see pronouns on the snapshot view of a user profile when you hover over someone’s name on an issue or merge request. This helps users better respond to comments using the correct pronouns without needing to navigate to the user’s profile.
Track which groups across your organization have enabled SAST and DAST scanning. This is helpful for verifying compliance with organizational requirements, responding to audit requests, and tracking progress on company initiatives to make applications more secure. To track adoption, go to the Sec tab in DevOps Adoption either at the group level or instance level.
To see groups that have enabled fuzz testing and dependency scanning, use the DevOps API. Fuzz testing and dependency scanning will be added to the DevOps Adoption UI in an upcoming release.
When reviewing a merge request (MR) in Visual Studio Code it can be helpful to check out the branch proposing the changes. Finding the source branch’s name and then switching context to check it out can be challenging.
Now when reviewing an MR with GitLab Workflow for Visual Studio Code you can right click the MR title to check out its source branch. This makes it easier to review the proposed changes in the larger context, test items locally, and perform other actions on the source branch.
When reviewing a merge request (MR) it can be helpful to make suggestions to many of the changed files. This is often done by creating a patch file with the suggestions and sharing it with others. The problem is that this requires several manual steps like running Git commands and uploading the patch file somewhere others can download it.
With GitLab Workflowv3.26.0 for VS Code you can now create and apply patches directly in your editor. The new GitLab: Create snippet patch command creates a patch with the changes in your editor and uploads that patch as a GitLab snippet.
Anyone can search for patches in the project’s snippets and apply them directly in VS Code with the GitLab: Apply snippet patch command. The applied changes can then be committed to the MR.
Sharing and collaborating around patches is a great way to propose more complex suggestions and provide clear improvements. Patches created in VS Code can also be linked to others through snippets and downloaded and applied outside of VS Code for users with different editing tools.
Data in CSV (comma-separated value) files is easier to understand when shown as a table with columns and rows, especially if the file is large. Previously, CSV information was presented as raw text in GitLab repositories. CSVs are now represented as a table, with the RAW view representing the actual comma separated values.
In GitLab 14.0, we introduced the Content Editor in the Wiki, a new WYSIWYG Markdown editor with support for basic content types like bold, italic, code, block quotes, and links. In 14.1, we’re adding the ability to format text with strikethrough and insert horizontal rules. Adding these frequently-used content types brings us closer to our goal of giving all users a rich editing experience without learning Markdown, with full support for the GitLab Flavored Markdown specification, to make this the default editing experience for the Wiki.
Previously, to manage runners programmatically, you had to fetch and manipulate data by using a REST API. As part of our plans to improve the administration of runners, we are implementing GraphQL as one foundational element in delivering a better user experience in the runner’s Admin Area UI. With this release, you can now use GraphQL queries and mutations to administer runners for your GitLab instance programmatically.
Today, you can register runners at the group and project levels in a GitLab instance by default. For some organizations with more stringent security controls, administrators need to limit the registration of project and group runners. This community contribution adds two configuration options in the Admin Area so that you can turn off the runner registration options at the project and group level. To test this feature, you will need to enable the :runner_registration_control feature flag.
Today, you can administer all runners in a GitLab instance from the Admin Area’s Runners page. However, the capabilities on this page are not helpful for GitLab administrators who are managing and operating a large fleet of runners. In this first of many planned iterations, the Admin Area’s Runners page now uses Vue.js and GraphQL. In this release, you will notice that the list and detail views are now consistent with other areas of the GitLab UI. This new architecture enables us to have a more interactive UI, iterate more quickly, and add new features and capabilities to help you administer and operate runners at scale.
Previously, you could only use the pipeline editor to work on your pipeline configuration in your project’s default branch. In this release, we are adding a branch selector to the pipeline editor. Now you can use the pipeline editor from any branch you’d like, which makes it much easier to test changes before implementing them on the default branch.
We are now disabling the jailing mechanism for GitLab Pages by default due to problems discovered when upgrading to GitLab 14.0. Jailing is no longer relevant since we stopped serving GitLab Pages directly from disk starting in 14.0. You can still re-enable jailing if you require the functionality though. In that case, please reach out to us on the Pages migration feedback issue, so that we can investigate your case.
In GitLab 13.2, we added the ability to associate issues to feature flags. In this release, we added the ability to associate feature flags with issues. An issue often has the context for the ‘why’. Allowing a user to be able to navigate from issue to feature flag, and back again will enable the user to have the complete context on what the feature flag is for.
In 2020, GitLab acquired Peach Tech and gained an incredibly powerful DAST API Security tool in the process. After initially focusing on the fuzz testing capabilities of the tools we acquired, we are proud to announce that the API Security scanner for DAST is now ready for use as a beta feature. This scanner immediately gives the benefit of enabling more API specification methods, more API language support, and additional authentication methods. In addition to the already supported OpenAPI specification, you can now use Postman collections and HAR files to provide multiple options for defining what can be tested in the API. In addition to supporting REST APIs, the new beta API Security scanner also supports SOAP and GraphQL API endpoints. Additional authentication methods include static cookies, form bodies, JSON bodies, and XML bodies. Dynamic headers, cookies, query strings, form bodies, JSON bodies, and XML bodies are also now supported via user-provided scripts that update the values.
As a part of this beta, the DAST API job for the API Security scanner is now separate from the traditional web application DAST job in your CI/CD pipeline. The DAST API job can be configured separately, using new variables and a new DAST API YAML template. This is a major improvement that enables usage of both web application DAST and API DAST in the same pipeline. You no longer have to choose between one type of DAST scan or the other when testing your applications. One pipeline can provide dynamic application security test coverage of both the UI and API of an application.
While this new scanner gives us a major improvement in functionality, we have identified that there are multiple vulnerability checks that need to be implemented in order to provide vulnerability coverage parity with the current DAST API scanner. We will continue to work on building those vulnerability checks to get the API Security scanner to a GA maturity. During the beta period, we strongly encourage usage of the new scanner and welcome any feedback.
Following in the footsteps of the GitLab SAST configuration tool we added support for Secret Detection on the Security Configuration page in 13.12. We believe that security is a team effort and this configuration experience makes it easier for non-CI experts to get started with GitLab Secret Detection which is why we’re making this tool available for all SaaS users in 14.1, and all self-managed users soon. The tool helps a user create a merge request to enable Secret Detection scanning while leveraging best configuration practices like using the GitLab-managed SAST.gitlab-ci.yml template. The Configuration tool can create a new .gitlab-ci.yml file if one does not exist or update existing simple GitLab CI files, allowing the tool to be used with projects that already have GitLab CI set up.
Users with access to the Security Configuration page who do not yet have Dependency Scanning enabled can now enable it by clicking “Configure via Merge Request”. This will create and/or update your pipeline YAML file to add the default Dependency Scanning template. This will make it easier for you to quickly add Dependency Scanning into your project providing an additional layer of security to your standard development workflow.
GitLab now supports a Universal Baseline Image (UBI) version of the container scanning image. By default, GitLab container scanning runs on an Alpine-based image. However, you may prefer or require it to run on a UBI-based image instead. You can now choose to have your container scanning jobs run on a UBI-based image by following these steps.
GitLab 14.1 includes Mattermost 5.36, an open source Slack-alternative whose newest release includes the addition of Hungarian language support, a Focalboard project management integration (beta), and more. This version also includes security updates and upgrading from earlier versions is recommended.
GitLab 14.1 also introduces the ability to opt-in to PostgreSQL 13 for fresh single-node installations not using Geo or a multi-node setup. This prompt allows users to benefit from the features and functions associated with the latest version of PostgreSQL.
GitLab users expressed a need for more modern practices related to NGINX TLS configuration in GitLab instances. In 14.1, the SSL configuration is updated to use the intermediate setting from Mozilla’s SSL configurator.
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 14.1, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 14.1 are:
According to the Docker Image Spec and the OCI Image Spec, a manifest list should reference only manifests. We learned that it’s possible to push manifest lists that reference layers. The root cause lies with Docker’s Buildkit (directly or through Buildx) implementation of remote cache images. It has been reported upstream, but it isn’t clear if this issue will be addressed. We have short-term and long-term goals for dealing with this.
Short term, our goal is to unblock Self-Managed customers from running offline garbage collection. For now, we updated the container registry to account for this behavior.
Long term, we must ensure that the GitLab Container Registry enforces the OCI Image Spec. Allowing manifest lists with blobs to be pushed affects data integrity and consistency. However, adding validation would introduce breaking changes for GitLab.com and Self-Managed customers. We’re gathering data on the scope of the issue and will follow up with a plan in the coming months.
In the meantime, if you have any questions, please comment in the issue.
Maximum file size for job logs, defaulting to 100MB
GitLab values efficiency for all users in our wider community of contributors, so we’re always working hard to make sure the application performs at a high level with a lovable UX. In 14.2, we plan on introducing a job log file size limit, set to 100 megabytes by default. Administrators of self-managed GitLab instances can customize this to any value. All jobs that exceed this limit are dropped and marked as failed, helping prevent performance impacts or over-use of resources. This ensures that everyone using GitLab has the best possible experience.
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