GitLab 13.1 released with Alert Management and Code Quality Enhancements
GitLab 13.1 released with Alert Management, Code Quality, Security & Compliance Improvements
GitLab 13.1 is now available, bringing you expanded alert management, new tools to help you track and improve code quality, and more ways to keep your code secure and compliant.
Automate and expand Alert Management
Alerts are essential to application maintenance, but understanding and triaging the range of alerts thrown can dramatically reduce productivity and response time. GitLab’s Alert Management aggregates and ranks IT alerts from all of your services to simplify assessment and remediation, increasing productivity and helping you research and address critical issues right away. Key features in 13.1 include alert assignments, Slack integration, and creating GitLab To-Dos when assigning alerts.
Improve code quality
Deployment velocity only matters if you’re deploying high quality code. By prioritizing tests on recently modified code, developers can address errors immediately, without running an entire test suite. Code coverage tracking over time surfaces quality trends to developers and managers alike, and native code intelligence boosts the speed and accuracy of code reviews by integrating reference material directly into GitLab.
Enhance and extend security and compliance
Security matters to everyone, and we're committed to lowering the barriers to a fully secure, compliant SDLC. That's why we're happy to announce that we've migrated Brakeman SAST scanning to Core, allowing every Rails developer—at every product tier—to scan their source code for known vulnerabilities. For compliance-focused organizations, we've released a policy management UI for network container policies, and we've enabled group-level vulnerability exports to a CSV file for audits or further internal review. In addition, we've made helpful UX improvements to the Security Dashboard, adding persistent filters and issue status icons to help maintain context as you work within the tool.
Jacopo added new email notifications when pipelines are fixed.
Until now, GitLab sent notification emails when a pipeline failed, but when the pipeline was fixed, no notification of the fix was sent. Developers needed
to repeatedly reload the merge request or pipeline views to check the status. This great contribution solves this problem and saves developer frustration.
This contribution took about 8 months, but Jacopo worked on it and managed to get it across the finish line. It received approvals from 5 different reviewers. It’s received great feedback from everyone within GitLab and lots of interest, with over 30 upvotes on the issue, and nearly 70 active conversations related to it.
Jacopo, thanks for this wonderful contribution, we really appreciate it!
When firefighting, responders must coordinate multiple tools and evaluate different data sources to collect and assess metrics, logs, and traces. Sharing these with a response team involves screen-grabbing, then copying and pasting data into a single ticket, to keep all stakeholders informed. This work is manual, time-consuming, tiring, and stressful. It leads to alert fatigue, increased stress, sinking morale, and - most importantly - missed alerts.
In GitLab 13.2 and beyond, we plan to improve alert and incident response workflows by integrating with PagerDuty, surfacing relevant metrics and logs on alerts, associating runbooks, and creating an Alert Integration Builder, so your operators can self-serve and seamlessly integrate GitLab with any monitoring tool. To view our progress and suggest ideas for future improvements, see the Alert Management epic.
In this release, we redesigned the feature flags UI to enable setting strategies for multiple environments. Previously, it was much more difficult to manage Feature Flags and set strategies as the number of environments increased. This improvement gives you more flexibility to create and apply strategies to environments at-scale.
Today, developers who want to ensure their application is accessible to everyone suffer from slow feedback loops, which make it difficult to catch degradations in their code. GitLab’s full accessibility report was a start, but using that report to see what has changed in a single Merge Request is a manual and slow process.
In GitLab 13.1, merge requests can have a widget that details accessibility degradations related to the changed pages. This will immediately show developers the impact of their changes, which helps prevent degradations before they are merged and deployed.
When you receive lots of feedback on a Design, the number of comment pins can build up quickly! As your discussion thread grows, it gets hard to know which discussions are complete and which still need work.
With 13.1, you’ll have the ability to mark any comment as Resolved to signify that it is now complete. Even better — your resolved comment pins will disappear from the Design so you can focus on what’s left! And, of course, if you need to revisit something, all of your resolved threads will be available in the Resolved Comment area at the bottom of the sidebar. From there, you can find them again and see which revision applied at the point of revision.
We think this will greatly improve your workflow so you can focus on what is important.
Originally introduced in GitLab 11.4 as a GitLab Premium feature,
Merge Request Reviews
allow merge request reviewers to submit multiple comments at once, cutting down on notification noise
for the merge request author, and allowing for a more cohesive and streamlined review process.
Since its introduction, we’ve re-evaluated its place in our
buyer-based pricing model
and as part of 13.1 we’re excited to announce this feature has now moved to GitLab Core.
Code review is an important process that requires an understanding of the proposed change
and surrounding code to know if it has been made in a maintainable way. Easily browsing definitions while writing new code
or reviewing changes to existing code allows developers to gain a better understanding
of the software being written. This is extremely useful when reviewing new code as well as code
changes in merge requests. However, setting up browsable definitions generally meant configuring
external tools and resources, or using a dedicated IDE. With GitLab, this is no longer the case.
Taking inspiration in the great work done by our partners at Sourcegraph
and powered by the LSIF format,
GitLab’s native Code Intelligence can be added to any project by adding a
new job to the project’s .gitlab-ci.yml file, which specifies an LSIF report.
Once generated, hovering over objects in your code will present the available
code intelligence actions. No external tools or IDEs required.
Future iterations will include the ability to find references, as well as API support. You can
follow along in the Code Intelligence epic.
GitLab already supports the ability to control feature rollout based on user IDs.
However, it’s tedious to repeatedly add more users for every flag or environment.
To make this process more convenient, we have added a new Feature Flag strategy called “lists.”
User lists are created and modified with the API. After creation, use them by choosing the “list” strategy for your feature flag and selecting the appropriate list. If you already have lists created, you can use them right away.
All too often, a project has a code coverage target but development teams might not have much visibility into which direction that target value is trending over time. There needs to be an easier way to track changes in code coverage over time without that extra hassle.
The Code Coverage graph now provides better visibility into how code coverage is trending over time. It displays a simple graph of the coverage value(s) calculated in pipelines. We are looking forward to feedback from customers on this feature as we plan improvements and future iterations.
Now that you’re able to create requirements in GitLab, the next step towards a full requirements management solution is showing your requirements are satisfied.
We’re excited to release the first step by allowing you to configure jobs within the standard CI pipeline that, when triggered, will mark all existing requirements as satisfied. This CI job can be either manual or automatic, and like other CI jobs can be configured to allow failure so it doesn’t block the pipeline from completing. Future iterations will allow selectively satisfying requirements from pipeline testing as well as allowing our customers performing manual verification to indicate satisfied requirements through the interface.
The Users API /user/keys and /users/:id/keys endpoints now support an optional expires_at parameter to define an expiration date for SSH keys. This change can help users and organizations manage the impact of a compromised credential in a regulated environment.
GitLab’s Audit Events API has been extended to add an endpoint for projects, enabling group owners to poll the API for specific project-level data. This change makes it easier to find and retrieve the data you need to manage your compliance programs, and build out tooling you need for the auditability and traceability of your GitLab projects.
Issue Analytics allows users to quickly spot trends in issue data. To enhance this ability, you now have a table that lists key details such as issue age, status, milestone, weight, due date, assignees, and author. With this additional visibility, users may now follow the thread of their inquiry beyond the chart and into the specific issues behind the trend.
IP access restriction is now available for Premium and Silver tiers. This feature allows you to restrict access to groups and their underlying content by one or more IP subnets. Enabling IP access restriction ensures that particular content doesn’t leave the premises, while not blocking off access to the entire instance.
GitLab loves to make user workflows as easy as possible. You can now assign an issue to a commenter, right next to the comment, with the click of a button. This keeps your focus and effort centered around the comments, rather than having to navigate to the side panel or use a quick assign command.
Gitaly Cluster allows you to replicate Git repositories on multiple warm
Gitaly nodes, improving fault tolerance by removing single points of
failure.
In GitLab 13.1, Git read operations can be distributed between up-to-date
Gitaly replicas. This makes better use of the available resources, and can
improve performance.
This feature is being released as
beta while we evaluate its performance
under production loads.
Gitaly Cluster improves fault tolerance of Git storage in GitLab by removing single points of failure, detecting
outages, and automatically switching to a replica. From GitLab 13.1, when Gitaly Cluster is configured, SQL leader
election and automatic failover are enabled by default.
If unreplicated write operations are detected during failover, the cluster is put into read only mode to prevent
a split brain. In the future,
strong consistency will require that write operations succeed
on multiple Gitaly nodes before responding with a success signal, preventing this problem and the need to mark the
cluster read only.
Previously in GitLab 13.0, in memory leader election was default instead of automatic failover.
The Static Site Editor offers immediate visual feedback when writing Markdown content, and intuitive formatting controls to ensure consistent and accurate markup. However, this visual editing experience introduced in GitLab 13.0 was limited to text content.
In GitLab 13.1, you can quickly add images to your pages using the Static Site Editor. After clicking the Image icon in the formatting bar, just link to a URL, add optional ALT text, and you’re done. The link can reference images already hosted in your project, an asset hosted externally on a content delivery network, or any other external URL. The editor renders thumbnail previews so you can verify the correct image is included and there aren’t any references to missing images.
Earlier in 2020, GitLab committed to moving 18 features to our open source core product. With this release of GitLab we’ve completed the work to move both the Web Terminal and File Sync utility to Core. We’re excited about bringing these features to more users, and seeing what use cases and workflows you’re able to use them for.
We’re also releasing GitLab Runner 13.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.
As a developer, you want to get feedback quickly about your changes, including results of newly-written tests. In large projects like GitLab, this can be especially difficult with wait times up to 45 minutes just to see a new unit test pass, or — even worse — fail. This slowness can lead you to skip automated test development entirely.
Ruby developers can shorten the feedback loop by using the TestFileFinder gem to find tests that target the modified code, then running those tests in an early stage in the pipeline. This is an MVC approach to solving the problem, but one we hope you’re excited about. We look forward to feedback and ideas in the TestFileFinder project.
When a NuGet package is uploaded to GitLab, a job opens the archive and reads the .nuspec file. The package name and version are extracted, but several other fields, like dependencies, project_url and tags are available but not extracted. These fields are useful for understanding how a package has been built and what its dependencies are.
In GitLab 13.1, we are excited to announce that this metadata will now be extracted as part of the upload and included in the user interface so that you validate that package was built properly.
We’ve documented an example of a blue-green deployment using NGINX that swaps the deployments directly from the .gitlab-ci.yml file. This example will help you set up blue-green deployments if you’re using a similar configuration, and provides guidance you can customize for other types of applications.
Setting up AWS deployments is not always as easy as we’d like it to be. To make it easier for you to use our AWS features, we’ve added in-product links to our AWS templates and documentation when you start adding AWS CI/CD variables. These links should help you get up and running faster.
You can run GitLab-integrated Terraform features more easily with one of the GitLab-provided Terraform images. The GitLab Terraform images extend the official Terraform images for Terraform versions 0.12 and 0.13 beta by including simple commands to use Merge Request widgets without bloating your CI/CD YAML files.
The ability to audit alerts is important for feedback and improvement, but there’s rarely time during a fire-fight to document the details you’ll need later. In GitLab 13.1, alert assignments are added to the system notes of an Alert so you can discuss them in your post-incident review.
We’ve added commands to our Slack notifications service so you can forward Alerts to Slack, notifying responders of an outage, and enabling responders to begin collaborating without leaving their central communication platform.
Responders can now assign alerts to team members to help organize triggered alerts, delegating problems for investigation by a specific team member. Adding a GitLab To-Do list item tells the team member something needs their attention.
Metric panels are most useful when they facilitate drill-down. In GitLab 13.1, you can add custom URLs to the More actions menu for panels in your metrics dashboard, cross-linking your metrics panel and dashboard with other metrics dashboards and additional troubleshooting tools your team uses.
GitLab 13.1 now enables metrics dashboards to display time in UTC, enabling distributed team members working together to see the same time-series data, regardless of the team members’ physical locations.
In GitLab 13.1, Omnibus GitLab users will have a new out-of-the-box dashboard in their self-monitoring project to monitor the health of their GitLab instance.
GitLab allows you to define pipeline job artifacts, making them easy to browse and download in the GitLab UI. Previously, you could only download the entire artifact archive for a pipeline or job.
We wanted to make it faster and easier to quickly access any report artifact file directly. This is particularly useful for Security scanning reports and code quality reports which you may want to download for use in other tools.
With GitLab 13.1 we added support for downloading the following types of individual artifact reports:
accessibility
archive
cobertura
codequality
container_scanning
dast
dependency_scanning
dotenv
junit
license_management
license_scanning
lsif
metrics
performance
This feature is available for all GitLab users. However, artifact report types vary across GitLab tiers.
From the Group Security Dashboard, you can now download a CSV file containing
detected vulnerabilities for all projects in a group. This export list can
then be used for things such as creating compliance reports or as a data
source for external dashboards. This joins the ability to export
reports from the Instance
and Project Security Dashboards.
Simply go to any Group Security Dashboard and click the new ‘Export’
button. Your browser will automatically start the download.
Secret Detection has been promoted from a sub-feature of SAST to a category of its own. Secret Detection findings are now more visible, displaying in their own section in merge requests and pipeline security tabs. Secret Detection will also now display configuration status on the Security Configuration Page and display findings in Project Security Dashboards.
The extraEnv pattern is now supported in the GitLab Helm charts. This allows you to expose additional environment variables, such as proxy servers, for specific GitLab charts or globally for all GitLab charts. Refer to the global settings documentation or subchart documentation for details on how to implement extraEnv.
Custom annotations configured in the deployment section of the global settings in values.yml are now available in all GitLab subcharts. Deployment annotations allow you to grant access at the deployment level rather than the node level, such as allowing a deployment to read an Amazon S3 bucket without having to grant the entire node access to the bucket. For details on how to set up deployment annotations, see the Annotations documentation.
The PostgreSQL libraries and client in the GitLab container images have been updated to PostgreSQL 12 to allow using more versions of PostgreSQL. Note that GitLab 13.1 still only supports PostgreSQL 11, but support for PostgreSQL 12 is planned for a future release.
For improved security, you can now pass a Kubernetes secret for sensitive header values such as Authorization token for the endpoints when configuring Registry notifications. For setup, see the Registry chart documentation.
The version of NGINX bundled in Omnibus GitLab has been updated from 1.16.1 to 1.18.0.
The expiration of the GPG key used to sign GitLab Omnibus packages has been extended to July 2021. If you validate the signatures of the Omnibus package for your installation, you must also update your copy of the signing key. Note that this key is separate to the repository signing key that was updated in April 2020. See the Omnibus documentation for instructions on how to update the key.
GitLab 13.1 includes Mattermost 5.23, an open source Slack alternative. The newest release includes automatic hyperlinking to Jira issues and more. This version also includes security updates, and upgrade from earlier versions is recommended.
If you’ve ever used the search API, you might have noticed that some scope searches were averaging a response time of over 11000ms. This was clearly not very efficient.
In GitLab 13.1, we addressed some N+1 database calls and as a result, we saw a 40% improvement in the response times! Scope searches have never been faster.
In GitLab 13.1, the search dropdown now gives you the option of searching in the group from a project that belongs to the group.
Before GitLab 13.1, the search dropdown options did not include in this group if searching from a project.
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.1, we’re shipping performance improvements for CI pipeline processing, viewing git blame, and much more! Some improvements in GitLab 13.1 are:
When an SSH key is created for a user via the API, either by the user or an administrator, you will now see this action logged in the audit events table. Previously, these actions were not logged and created a gap in the auditability of SSH credentials for a user.
Contribution Analytics helps teams understand how workload is balanced across many participants. Until now, the contributions of merge request approvers were overlooked, despite their valuable role in ensuring merge requests receive an appropriate level of review. The table of contributions per group member now includes a sortable Approved MRs column to display approvers by the number of approvals completed.
In GitLab 13.1, Owners can now restrict group membership to users with email addresses across multiple domains instead of a single domain. This new configuration option will give you greater flexibility while securing access to your group.
One of the most important aspects of compliance is knowing who can access your business systems and resources. You need to know what role or permissions they possess so you can audit that access against your policies. Generating this type of evidence should be easy, so we’ve added a new API to provide group and project memberships for a user. You can now programmatically list all of the groups and projects a user belongs to along with their respective role for each resource. You no longer need to search through groups, projects, and logs to aggregate this data.
Issue titles will now always remain visible at the top of the issue, regardless of what part of the issue you’re reading. This ensures that you’ll always have context, regardless of whether you’ve clicked a link to a deep conversation thread, scrolled deep within an issue, or you’re working with multiple tabs of similar issues.
Developers collaborating on projects follow certain coding standards and styles to maintain consistent levels of readability and formatting in the project. This configuration is often done through an .editorconfig file inside of the project which provides instructions like indent style, indent size, and line endings.
When opening a file, the Web IDE looks for a file named .editorconfig in the current directory and all parent directories. If a config file is found and has settings that match the file’s path, the settings will be enforced on the opened file. The Web IDE provides support for most of the widely supported features of EditorConfig with an exception for charset.
Static site generators consume the first few lines (“front matter”) at the beginning of a Markdown file, between two --- lines, to format, configure, or parse the page. Front matter isn’t meant to be displayed alongside the content of the page, and must conform to specific formatting rules.
GitLab’s Static Site Editor now includes a rich content editing experience that parses the Markdown syntax and displays it in a more familiar style. However, the front matter, not being intended for display, gets rendered unexpectedly in this context, and editing it using the visual editor can have unintended consequences.
GitLab 13.1 hides any YAML-formatted front matter included at the beginning of the Markdown file to prevent any confusion or unintended formatting changes. The front matter remains editable in the raw source editor, available by toggling the editor mode in the bottom right of the Static Site Editor.
When working with Markdown content in the Web IDE, you may need to add images to the content. Adding images in most editors requires finding that image, adding it to the directory structure and then referencing it through markdown syntax.
The Web IDE now supports pasting images directly into the editing window. Copy an image to your clipboard, place your cursor in your the Web IDE where you’d like the image to appear, and paste. The image will automatically be uploaded to your project and appropriately referenced inside of your content, greatly speeding up the content creation process and reducing complexity for users.
You can now filter by pipeline status or by tag name on the pipelines page. With filtering, viewing all pipelines for a specific tag, or narrowing the list of pipelines to a specific pipeline status (such as failed or skipped) is much easier. With these additions to the existing filter options, pinpointing your desired pipeline is easier than ever, and saves time in your day.
GitLab now supports instance-level variables. With this ability to set global variables, you no longer need to manually enter the same credentials repeatedly for all your projects. This MVC introduces access to this feature by API, and the next iteration of this feature will provide the ability to configure instance-level variables directly in the UI.
It can be hard to figure out how to use the new rules keyword, especially if you previously used only/except, as the two are fundamentally different. The rules keyword creates a merge request pipeline by default, and only/except doesn’t.
To ease getting started, and getting to your first green pipeline with rules more quickly, we’ve added the two most common workflow: rules configurations as bundled templates. These make it much easier to get things working right away, letting you focus on what’s important.
You can now create feature flag strategies and apply them to environments via a public API. Previously, strategies were bound to environments. Introducing new strategies required defining additional environments and attaching them to these environments. This new API will allow for defining strategies independent of environments.
Changing your infrastructure is always a high-risk action; it should always be supervised, audited, and restricted to team members with permission. We introduced the GitLab-managed Terraform state with a known limitation in GitLab 13.0: you were required to provide a personal access token to work with the state file. This option did not scale well.
Starting with GitLab 13.1, we’ve extended the scope of the auto-generated CI token with the acting user’s credentials. The token is designed specifically to run Terraform state management jobs, enabling you to securely run Terraform job pipelines without any additional setup.
Each time a pipeline fails, you automatically receive an email notification. However, when the pipeline succeeds after failure, no automatic notification is sent, which requires you to manually check the pipeline’s status. In this release, we are excited to include a community contribution by @jacopo-beschi that solves this problem by automatically notifying you if a pipeline succeeds after a failure.
GitLab now lets you conveniently specify the kind of asset link you have added to your Release with a dropdown menu. Previously, if you added links to a release, you were unable to communicate what type of asset it was. With this addition, you can choose the type of asset from the following options: “Runbook”, “Package”, “Image”, or “Other.”
In GitLab 13.1, you can assign GitLab alerts to specific users on your team, streamlining triage workflows, delegating problems that require investigation, and ensuring no critical alert gets dropped.
Alerts are often noisy and plentiful. To make it easier for you to find the newest or most severe alerts quickly, you can now sort the alert list by descending and ascending values.
Understanding charts without appropriate context can be difficult. In GitLab 13.1, we made it easier for you to compare data when inspecting charts by displaying chart legends in a tabular format.
A Metric Dashboard is often related to other dashboards. With Dashboard Links, you can display links to related GitLab Metrics and Grafana dashboards that preserve the time window of the dashboard you’re currently viewing.
Configuring a dashboard YAML file can be complex and error-prone. GitLab 13.1 adds validation to your YAML file to help you diagnose problems with your metrics dashboard by displaying a warning message
if your dashboard YAML definition is invalid.
Images included in issue descriptions published to GitLab status pages now render, giving meaningful context to customers, users, and stakeholders to help them make decisions about how to handle outages and performance degradations. Sharing visuals along with text raises transparency, which encourages user trust and confidence.
Previously, in Security Dashboards, vulnerability list items with an
associated issue displayed a static icon with a link to the issue. With
this usability improvement, the icon now dynamically reflects whether the
issue is open or closed. At a glance, you can now tell if a vulnerability
might need additional attention.
GitLab 13.0 introduced standalone vulnerability pages as an important
step towards the future of Vulnerability Management. The switch from popup
information boxes to independent pages, however, presented some new UI
considerations.
Navigating from the Security Dashboards to a vulnerability page and back
previously cleared any filters applied on the dashboard. We received
good feedback that improving this experience would improve the vulnerability
triage and management experience. Your filters now
persist when moving between vulnerability pages and a dashboard,
greatly improving the efficiency of managing vulnerabilities. It also matches
a familiar UX pattern found elsewhere in GitLab, such as managing your To-Do
list.
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 mitigate them proactively. As part of our community stewardship commitment, we are making our Rails SAST analyzer (Brakeman) available in every GitLab tier. This will allow ALL GitLab users developing in Rails to leverage SAST Security Scans for their projects.
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 contribute to this effort.
With the first release of a policy management UI for Container Network Policies,
users can easily scan a list of Network Policies deployed in their project
and enable or disable those policies through GitLab’s UI. You can find the new policy management experience
at Security & Compliance -> Threat Management -> Policies.
When performing a failover using GitLab Geo, systems administrators should perform a number of preflight checks before promoting a secondary to a primary to ensure that the failover is successful. Many of these preflight checks are manual, thereby increasing the chance of user errors.
In GitLab 13.1, Geo includes a new command gitlab-ctl promotion-preflight-checks that lists all required preflight checks and asks systems administrators to confirm that these checks were executed. The command is automatically run when running gitlab-ctl promote-to-primary-node.
You can now use AWS IAM roles for accessing encrypted S3 buckets. Previously, encrypted S3 buckets would not work at all. To learn more, see the Object Storage documentation.
In previous versions of GitLab, Advanced Global Search’s indexing process supported partial matching by storing a list of all partial words in the index. Partial words provide better results for natural-language search queries, but users performing code searches frequently search for specific text, like function definitions.
Partial matching for code has been disabled in GitLab 13.1, reducing the index size by 75%. If desired, users can continue using partial matching by using wildcards in their code search query. Partial matching for other content types, like issues or merge requests, is still supported.
Self-managed customers who have enabled Advanced Global Search must reindex after updating to take advantage of this reduction in index size.
To help maintain overall performance for everyone using gitlab.com, the job archive date will be set to 3 months. Here’s a quick reminder of what you can and cannot do with an archived job. Once a job is archived:
You can still view the job, logs, associated pipelines, and deployments, as well as rerun the entire pipeline.
You can’t retry, rerun, or trigger the job, or trigger a deployment from the job.
Existing jobs that were generated before March 22nd, 2020 will be archived by September 22nd, 2020.
Default artifact expiration changed to 30 days on gitlab.com
To help maintain the overall performance for everyone using gitlab.com, the expiration for pipeline artifacts will be set to 30 days on gitlab.com. The artifacts from the last successful job will not be archived until 30 days after a newer job generates new artifacts. Artifacts without expiration dates will not be changed, but a future update will add an expiration date to them as well.
Deployment template for AWS ECS is moving to a new location
We are changing the location of the Deploy to AWS ECS gitlab-ci.yml template. If you have referenced this template in your CI/CD configuration, please update it by replacing template: Deploy-ECS.gitlab-ci.yml with template: AWS/Deploy-ECS.gitlab-ci.yml. We are expanding our supported AWS targets, and all future AWS-related templates will be found in the AWS template folder.
GitLab is moving Auto DevOps from Herokuish buildpacks to Cloud Native Buildpacks, as Herokuish is essentially deprecated and Cloud Native Buildpacks are the next iteration of buildpack support. GitLab versions 12.10 and greater support Cloud Native Buildpacks. All new Auto DevOps projects will begin using Cloud Native Buildpacks in the next month, and Herokuish support will be dropped in October 2020.
Kubernetes 1.12 and 1.13 support is being deprecated for integration
For integrating Kubernetes with GitLab, we’ve introduced a Kubernetes support policy to provide GitLab users with clear upgrade timelines. Two deprecations are scheduled:
GitLab’s support for Kubernetes 1.12 ends on September 22, 2020.
GitLab’s support for Kubernetes 1.13 ends on November 22, 2020.
Various GitLab features may still work following these deprecations, but are not officially supported. GitLab is simultaneously working on adding support for more recent Kubernetes versions.
When deploying GitLab in Kubernetes, the minimum supported version of Kubernetes is now 1.13. Kubernetes 1.12 is no longer maintained upstream, and has recently been dropped by popular container management services such as GKE and EKS.
Feature Flag created before 13.1 are not compatible with the new architecture that we are developing. From 13.1, all new feature flags created on GitLab.com will be created with the new system by default. From 13.2, the same will be true for self-managed instances. Feature flags created in earlier versions can be edited until 13.4, and then they will become read-only. In 14.0, all legacy feature flags will be completely removed.
Planned removal of Docker-in-Docker (DinD) for security scanners
To increase the security and reduce complexity of scans, use of Docker-in-Docker (DinD) in GitLab Secure scanners was deprecated in 13.0 and is scheduled for removal in 13.4. GitLab security products started to use non-DinD mode by default in vendored templates in GitLab 13.0. We encourage customers to update their vendored templates to use this new behavior. If you override or use custom Secure CI templates, you can follow the guides below to disable Docker in Docker (DinD) from your existing job templates:
Configuration values used by
server-side Git hooks
in Gitaly were stored in gitlab-shell/config.yml. They are now stored in Gitaly’s
config.toml file under the [gitlab] and [hooks] TOML sections.
Before upgrading to GitLab 13.1, you must upgrade to GitLab 13.0, or — if you are using the Helm chart install — to the 4.0 version of the chart. For more information on recommended upgrade paths, see the Upgrade recommendations.
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