Rapid Secret Leak Detection
It may seem like a small mistake — accidentally sharing credentials in a public repository. However, the consequences can be severe. Once an attacker gains access to your password or API key, they can take over your account, lock you out, and fraudulently use funds. Additionally, there can be a domino effect: access to one account can lead to access to others. The stakes are high, making it crucial to detect secret leaks as soon as possible.
In this release, we introduce the option within our SAST functionality. Each commit is scanned for secrets during the CI/CD job. If a secret is found, the developer receives a warning in the merge request. They can immediately revoke the leaked credentials and create new ones.
Ensuring Proper Change Management
As organizations grow and become more complex, maintaining consistency across different parts of the organization becomes increasingly challenging. The more users an application has and the higher the revenue, the more serious the consequences of merging incorrect or insecure code. For many organizations, ensuring a proper review process before code merge is a strict requirement, as the risks are very high.
In GitLab 11.9, there is more control and a more effective structure — thanks to Previously, to obtain approval, it was sufficient to specify an individual or a group (each member of which could grant approval). Now it’s possible to add multiple rules so that a merge request requires approval from specific individuals or even multiple members of a specific group. Additionally, the Code Owners feature is integrated into the approval rules, making it easy to identify the person who granted the approval.
This enables organizations to implement complex approval processes while maintaining the simplicity of a single GitLab application, where tasks, code, pipelines, and monitoring data are visible and accessible for decision-making and accelerating the approval process.
ChatOps is now open source
GitLab ChatOps is an effective automation tool that allows you to run any CI/CD job and check its status directly in chat applications like Slack and Mattermost. , ChatOps was part of the GitLab Ultimate subscription. Based on and , we sometimes move features down a level and never up.
In the case of ChatOps, we realized that this functionality could be useful to everyone, and that community involvement could benefit the feature itself.
In GitLab 11.9 we , thus it is now freely available for use in self-managed GitLab Core and on GitLab.com and open to the community.
And much more!
This release has so many amazing features: for example, , and , — we can’t wait to tell you about them!
The most valuable employee of the month () is Marcel Amirault ()
Marcel has continually helped us improve the GitLab documentation. He to enhance the quality and usability of our documents. Domo arigato [thank you very much (Japanese) — ed.] Marcel, we truly appreciate it!
Key features added in GitLab 11.9
Detection of secrets and credentials in the repository
(ULTIMATE, GOLD)
Sometimes developers unintentionally push secrets and credentials to remote repositories. If others have access to this source, or if the project is public, confidential information is exposed and can be exploited by malicious actors to access resources such as deployment environments.
GitLab 11.9 has a new test — 'Secret Detection'. It scans the contents of the repository for API keys and other information that shouldn't be there. GitLab displays the results in the SAST report in the merge request widget, pipeline reports, and on security dashboards.
If you have already enabled SAST for your application, you don’t need to do anything, just enjoy the benefits of this new feature. It is also included in the configuration by default.
Merge request approval rules
(PREMIUM, ULTIMATE, SILVER, GOLD)
Code reviewing is an essential part of every successful project, but it is not always clear who should handle the review of changes. Often, it is desirable to involve reviewers from different teams: the development team, the user interaction team, and the production team.
Approval rules enhance the interaction process among those involved in code review: they define the circle of authorized approvers and the minimum number of approvals required. The approval rules are displayed in the merge request widget, allowing for quick appointment of the next reviewer.
In GitLab 11.8, approval rules were disabled by default. Starting with GitLab 11.9, they are available by default. In GitLab 11.3, we introduced the option to designate team members responsible for specific code within the project. The Code Owners feature is integrated into the approval rules, making it easy to find the right people for reviewing changes.
Moving ChatOps to Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Originally introduced in GitLab Ultimate 10.6, ChatOps has moved to GitLab Core. GitLab ChatOps offers the ability to run GitLab CI jobs through Slack using the .
We are open-sourcing this feature in accordance with our . The more it is used, the greater the community contribution.
Function parameter audits
(PREMIUM, ULTIMATE, SILVER, GOLD)
Operations such as adding, removing, or changing function parameters are now logged in GitLab's audit log, allowing you to see what was changed and when. Did an incident occur and you need to check what changed recently? Or do you simply need to verify how function parameters were modified during an audit? This is now very easy to do.
Merge request vulnerability remediation
(ULTIMATE, GOLD)
To quickly address code vulnerabilities, the process must be straightforward. It is crucial to simplify security fixes, allowing developers to focus on their core responsibilities. In GitLab 11.7, we , but it had to be downloaded, applied locally, and then pushed to the remote repository.
In GitLab 11.9, this process is automated. Fix vulnerabilities right from the GitLab web interface. Merge requests can be created directly from the vulnerability information window, and this new branch will already contain the fix. Once you've verified that the issue is resolved, add the fix back to the main branch if the pipeline is fine.
Displaying container scan results on the group's security dashboard
(ULTIMATE, GOLD)
The group's security dashboard allows specialists to focus on the most crucial issues by providing a clear and detailed overview of all potential vulnerabilities that could impact applications. This is why it's important for the dashboard to contain all necessary information in one place and allow users to delve into the data before addressing vulnerabilities.
In GitLab 11.9, container scan results have been added to the dashboard, alongside the existing SAST and dependency scanning results. Now, the entire overview is in one place, regardless of the source of the issue.
CI/CD templates for security jobs
(ULTIMATE, GOLD)
GitLab’s security features are evolving rapidly and constantly require updates to maintain code effectiveness and protection. Modifying job definitions is challenging when managing multiple projects. Additionally, we understand that no one wants to risk using the latest version of GitLab without certainty about its full compatibility with their current GitLab instance.
This is precisely why we introduced a new job definition mechanism in GitLab 11.7 using .
Starting from GitLab 11.9, we will offer built-in templates for all security jobs, such as sast and dependency_scanning, compatible with the corresponding version of GitLab.
Include them directly in your configuration, and they will be updated along with the system with each upgrade to a new version of GitLab. The pipeline configurations remain unchanged.
The new way to define security jobs is official and does not support any previous job definitions or code snippets. It is essential to update your definitions as soon as possible to use the new keyword
template. Support for any other syntax may be removed in GitLab 12.0 or in other future releases.
Other improvements in GitLab 11.9
Reply to comment
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab has discussions on topics. Until now, the user writing the initial comment had to decide from the start whether they needed a discussion.
We have relaxed this restriction. Take any comment in GitLab (on issues, merge requests, and epics) and reply to it, thereby starting the discussion. This allows teams to interact more organized.
Project templates for .NET, Go, iOS, and Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
To simplify the process for users creating new projects, we offer several new project templates:
- Starter , which includes a basic application with CI.
- A ready-to-use template that combines and GitLab CI/CD.
- , ready for initial customization in GitLab. Please note that, since building iOS requires a dedicated MacOS runner, you'll need to provide your own build server if you want to use it with GitLab CI/CD.
- are configured to work with Netlify.
Require merge request approvals from Code Owners
(PREMIUM, ULTIMATE, SILVER, GOLD)
It's not always clear who approves the merge request.
Now GitLab supports requiring approval of the merge request depending on which files the request changes, using . Code Owners are designated using a file called CODEOWNERS, formatted similarly to gitattributes.
Support for automatically assigning Code Owners as responsible for approving the merge request was added back in .
Moving files in Web IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Now, by renaming a file or directory, it can be moved from the Web IDE to the repository under a new path.
Labels in alphabetical order
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab labels are incredibly versatile, and teams are constantly finding new uses for them. Consequently, users often add many labels to an issue, merge request, or epic.
In GitLab 11.9, we have simplified the use of labels a bit. In issues, merge requests, and epics, the labels displayed in the sidebar are arranged in alphabetical order. This applies to viewing the list of these objects.
Quick comments when filtering actions by issue
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Recently, we introduced a feature that allows users to filter the activity feed by tasks, merge requests, or epics, enabling them to focus solely on comments or system notes. This setting is saved for each user in the system, and it can happen that a user may not realize that by viewing a task several days later, they are looking at a filtered feed. It may seem to them that they cannot leave a comment.
We have improved this interaction. Now users can quickly switch to a mode that allows them to leave comments without scrolling back to the very top of the feed. This applies to tasks, merge requests, and epics.
Changing the order of child epics
(ULTIMATE, GOLD)
We recently released , which enable the use of epics of epics (in addition to child tasks of epics).
Now it is possible to change the order of child epics of epics simply by dragging them, just like with child tasks. Teams can use the order to reflect priority or determine the sequence of work.
Custom header and footer system messages online and via email
(CORE, STARTER, PREMIUM, ULTIMATE)
Earlier, we added a feature that allows custom header and footer messages to appear on every page in GitLab. It was warmly received, and teams use it to share important information, such as system messages related to their GitLab instance.
We are excited to introduce this feature in Core, so now even more people can use it. Additionally, we allow users the option to display the same messages in all emails sent through GitLab for consistency with another point of user interaction with GitLab.
Filter by confidential tasks
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Confidential tasks are a useful tool for teams and enable closed discussions on sensitive topics within an open project. They are particularly well-suited for working on security vulnerabilities. Until now, managing confidential tasks has not been very easy.
In GitLab 11.9, the task list is now filtered by confidential or non-confidential tasks. This includes searching for tasks via the API.
Thanks for the contribution of Robert Schilling ()!
Editing the Knative domain after deployment
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Specifying a custom domain during Knative installation allows serving various serverless applications/functions with unique endpoints.
Now, Kubernetes integration in GitLab enables changing/updating the custom domain after deploying Knative to the Kubernetes cluster.
Verifying the format of the Kubernetes CA certificate
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
When adding an existing Kubernetes cluster, GitLab now checks that the entered CA certificate is in a valid PEM format. This eliminates potential integration errors.
Extending the comparison tool in merge requests to the entire file
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
While reviewing changes in a merge request, you can now expand the comparison tool for each file to show the whole file for more context and leave comments on unchanged lines.
Executing specific jobs for merge requests only when certain files are changed
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab 11.6, the ability to define for pipeline jobs was added, allowing users to run specific tasks only when a merge request is created.
Now we are expanding this functionality: a connection logic has been added , and users can execute specific jobs only for merge requests and only when certain files are changed.
Thanks for the contribution of Hiroyuki Sato ()!
Automatic monitoring of GitLab with Grafana
(CORE, STARTER, PREMIUM, ULTIMATE)
Grafana is now included in our Omnibus package, simplifying the understanding of how your instance operates.
Configure grafana['enable'] = true downward API support (simultaneously with this in gitlab.rb, and Grafana will be available at: https://your.gitlab.instance/-/grafana. In the near future, we will also out of the box.
Viewing parent epics on the epic sidebar
(ULTIMATE, GOLD)
Recently we introduced , allowing the use of epic of epics.
In GitLab 11.9, we simplified the mechanism for viewing this relationship. Now not only the parent epic of a given epic is visible, but the entire tree of epics on the sidebar to the right. You can see whether these epics are closed or not, and even directly navigate to them.
Link to the new task from the moved and closed task
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab, you can easily move a task to another project using the sidebar or a quick action. Behind the scenes, the existing task is closed, and a new task is created in the target project with all the copied data, including system notes and sidebar attributes. This is a great feature.
Given that there is a system note about the move, users may feel puzzled when viewing a closed task: they cannot help but realize that the task was closed due to being moved.
In this release, we indicate directly on the icon at the top of the closed task page that it has been moved, and we include an embedded link to the new task so anyone who lands on the old one can quickly navigate to the new one.
YouTrack Integration
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab integrates with many external issue tracking systems, making it easier for teams to use GitLab for other functionalities while still maintaining their chosen task management tool.
In this release, we added the ability to integrate with YouTrack from JetBrains.
Thanks to Kotau Yauhen for their contribution ()!
Resizing the file tree in merge requests
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
When viewing changes in a merge request, you can now resize the file tree to display long file names or save space on small screens.
Accessing recent task panels
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Task panels are very useful, and teams create several panels for each project and group. Recently, we added a search panel to quickly filter all the panels you are interested in.
In GitLab 11.9, we also introduced the section Recent in the dropdown. This way, you can quickly switch to the panels you interacted with recently.
Ability for developers to create protected branches
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Protected branches prevent moving or merging unreviewed code. However, if no one is allowed to move protected branches, no one can create a new protected branch: for example, a release branch.
In GitLab 11.9, developers can create protected branches from already protected branches through GitLab or the API. Using Git to move a new protected branch is still restricted—to avoid accidentally creating new protected branches.
Git object deduplication for open branches (Beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Branching allows anyone to participate in open-source projects: without write access, simply by copying the repository into a new project. Storing full copies of frequently branched Git repositories is inefficient. Now, with Git alternatives branches share common objects from the parent project in the object pool to reduce disk storage requirements.
Object pools for branches are created only for open projects if a hashed storage is connected. Object pools are enabled with a function parameter object_pools.
Filtering the list of merge requests by assigned approvers
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Code review is a common practice for any successful project, but it can be challenging for reviewers to keep track of merge requests.
In GitLab 11.9, the list of merge requests is filtered by the assigned approver. This way, you can find merge requests assigned to you as a reviewer.
Thanks for the contribution of Glavin Wiechert ()!
Keyboard shortcuts for the next and previous file in the merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
When viewing changes in a merge request, you can quickly switch between files using ]or j to go to the next file and [ or k to go to the previous file.
Simplification .gitlab-ci.yml for serverless projects
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Based on the functionality created by GitLab CI, the serverless template gitlab-ci.yml is significantly simplified. To introduce new features in future releases, changes to this file are not necessary.
Support for Ingress hostnames
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
During the deployment of the Kubernetes Ingress controller, some platforms revert to IP addresses (for example, GKE from Google), while others revert to DNS names (for example, EKS from AWS).
Our Kubernetes integration now supports both types of endpoints for display in the clusters the project.
Thanks for the contribution of Aaron Walker ()!
Access restriction for logging into JupyterHub only for group/project members
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Deploying JupyterHub using GitLab's integration with Kubernetes is a great way to maintain and use Jupyter Notebooks in large groups. It's also useful for controlling access when transferring confidential or personal data.
In GitLab 11.9, access to JupyterHub instances deployed via Kubernetes is limited to project members with 'developer' access level (through the group or project).
Custom time ranges for the security panel scheme
(ULTIMATE, GOLD)
The group security panel includes a vulnerability scheme for reviewing the current security status of group projects. This is very useful for security directors to tailor processes and understand how the team operates.
In GitLab 11.9, you can now select the time range for this vulnerability scheme. By default, it is the last 90 days, but you can set it to a 60 or 30-day interval, depending on the level of detail required.
This does not affect data in counters or lists, only the data points displayed on the scheme.
Adding an Auto DevOps build job for tags
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
The Auto DevOps build stage creates a build of your application using the project's Dockerfile or Heroku buildpack.
In GitLab 11.9, the resulting Docker image included in the tag pipeline is named similarly to traditional image names using the commit tag instead of the commit SHA.
Thank you for the contribution of Aaron Walker!
Updated Code Climate to version 0.83.0
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab use to check how changes affect the state of your code and project.
In GitLab 11.9, we updated the engine to the latest version (), to provide the benefits of additional language support and static analysis for GitLab Code Quality.
Thank you for the contribution from GitLab Core team member Takuya Noguchi ()!
Scaling and scrolling the metrics panel
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
When investigating performance anomalies, it is often helpful to take a closer look at specific parts of a particular metric.
With GitLab 11.9, users will be able to scale individual time periods on the metrics panel, scroll through the entire time range, and easily return to the view of the original time interval. This allows for quick and easy exploration of relevant events.
SAST for TypeScript
(ULTIMATE, GOLD)
is a relatively new programming language based on .
In GitLab 11.9, the Static Application Security Testing (SAST) feature analyzes and detects vulnerabilities in TypeScript code, showcasing them in the merge request widget, at the pipeline level, and on the security panel. The current job definition sast does not need to be changed, and it is also automatically included in .
SAST for multi-module Maven projects
(ULTIMATE, GOLD)
Maven projects are often organized to combine in one repository. Previously, GitLab could not properly scan such projects, and developers and security specialists did not receive vulnerability reports.
GitLab 11.9 offers enhanced SAST support for this specific project configuration, allowing you to test them for vulnerabilities in their source state. With the flexibility of analyzers, the configuration is automatically determined, and you do not need to change anything to view results for multi-module Maven applications. As usual, similar improvements are also available within .
GitLab Runner 11.9
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Today, we also released GitLab Runner 11.9! GitLab Runner is an open-source project used for running CI/CD jobs and sending results back to GitLab.
Below are some changes in GitLab Runner 11.9:
- .
- and .
- . This also .
- to support , which will appear in GitLab 11.10.
- .
- .
- Moved several scripts—including and — to Go.
- .
- .
- .
The full list of changes can be found in the GitLab Runner changelog: .
GitLab schema improvements
(CORE, STARTER, PREMIUM, ULTIMATE)
The following improvements have been made to the GitLab chart:
- Added support for Google Cloud Memorystore.
- Cron job settings , as they are used by multiple services.
- The registry has been updated to version 2.7.1.
- A new parameter has been added to ensure compatibility of the GitLab registry with Docker versions up to 1.10. To enable it, set
registry.compatibility.schema1.enabled: true.
Performance improvements
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
We continue to enhance GitLab performance with each release for GitLab instances of any size. Here are some improvements in GitLab 11.9:
- .
- .
- .
- .
Omnibus Improvements
(CORE, STARTER, PREMIUM, ULTIMATE)
The following improvements have been made in GitLab 11.9 Omnibus:
- GitLab 11.9 includes , , which includes MFA for Team Edition, improved image performance, and much more. This version also features ; an update is recommended.
- A new parameter has been added to ensure compatibility of the GitLab registry with Docker versions up to 1.10. To enable it, set
registry['compatibility_schema1_enabled'] = true in gitlab.rb. - GitLab registry now exports Prometheus metrics and is automatically monitored by the included .
- Support for Google Cloud Memorystore has been added, which requires .
opensslupdated to version 1.0.2r,nginx— updated to version 1.14.2,python— updated to version 3.4.9,jemalloc— updated to version 5.1.0,docutils— updated to version 0.13.1,gitlab-monitor— updated to version 3.2.0.
Deprecated features
GitLab Geo will provide hashed storage in GitLab 12.0
GitLab Geo requires to mitigate race conditions on secondary nodes. This was noted in .
In GitLab we have added this requirement to the Geo documentation: .
In GitLab sudo gitlab-rake gitlab:geo:check checks whether hashed storage is enabled and whether all projects are migrated. See . If you are using Geo, please run this check and migrate as soon as possible.
In GitLab Persistent deprecation warning will be displayed on the page Admin Area › Geo › Nodes, if the aforementioned checks are not resolved.
In GitLab Geo will utilize the requirements for hashed storage. See .
Removal date: June 22, 2019.
Hipchat integration
Hipchat . Additionally, in version 11.9 .
Removal date: March 22, 2019.
Support for CentOS 6 for GitLab Runner using Docker executor
GitLab Runner does not support CentOS 6 when using Docker in GitLab 11.9. This is due to an update in the underlying Docker library, which no longer supports CentOS 6. For more details, see .
Removal date: March 22, 2019.
Outdated legacy paths for GitLab Runner code
Starting with GitLab 11.9, GitLab Runner uses cloning/calling the repository. GitLab Runner will currently use the old method if the new one is not supported.
In GitLab 11.0, we changed the configuration viewing server for GitLab Runner. metrics_server will be removed in favor of listen_address in GitLab 12.0. For more details, see . And further details in .
In version 11.3, GitLab Runner began supporting , which led to new settings for . In a table of changes is provided along with instructions for transitioning to the new configuration. For more details, see .
These paths are no longer available in GitLab 12.0. As a user, you do not need to change anything, just ensure that your GitLab instance is running version 11.9+ when upgrading to GitLab Runner 12.0.
Removal date: June 22, 2019.
Deprecated parameter for the entry point feature for GitLab Runner
In 11.4, GitLab Runner introduced the feature parameter to fix issues such as and .
In GitLab 12.0, we will switch to the proper behavior, as if the feature parameter was disabled. For more details, see .
Removal date: June 22, 2019.
Deprecated support for Linux distributions that have reached EOL for GitLab Runner
Some Linux distributions that can install GitLab Runner have reached their end of life.
In GitLab 12.0, GitLab Runner will no longer distribute packages to these Linux distributions. A complete list of distributions that are no longer supported can be found in our . Thanks to Javier Jardón () for its !
Removal date: June 22, 2019.
Removal of old GitLab Runner Helper commands
As part of our efforts to support we had to drop some old commands that are used for .
In GitLab 12.0, GitLab Runner starts with new commands. This only applies to users who override . For more details, see .
Removal date: June 22, 2019.
Developers can delete Git tags in GitLab 11.10
Deleting or editing release notes for Git tags in unprotected branches has historically been limited to .
As developers can add tags, as well as modify and delete unprotected branches, they must have the ability to delete Git tags. In GitLab 11.10 to our permissions model to improve workflow and help developers use tags more effectively.
If you want to retain this restriction for maintainers and owners, use .
Removal date: April 22, 2019
Support for Prometheus 1.x in Omnibus GitLab
Starting from GitLab , the bundled version of Prometheus 1.0 is removed from Omnibus GitLab. . However, the metric format is incompatible with version 1.0. Existing versions can be upgraded to 2.0 and, if necessary, data can be migrated .
In GitLab version Prometheus 2.0 will be automatically installed if there have been no updates. Data from Prometheus 1.0 will be lost as it cannot be migrated.
Removal date: June 22, 2019.
TLS v1.1
Starting from GitLab to enhance security. This eliminates numerous vulnerabilities, including Heartbleed, and makes GitLab 'out of the box' compliant with PCI DSS 3.1.
To disable TLS v1.1 immediately, set nginx['ssl_protocols'] = "TLSv1.2" downward API support (simultaneously with this in gitlab.rband and run gitlab-ctl reconfigure.
Removal date: June 22, 2019.
OpenShift template for installing GitLab
Official — the recommended way to run GitLab on Kubernetes, including .
for installing GitLab is deprecated and will no longer be supported in .
Removal date: June 22, 2019.
Previous definitions of security jobs
With the introduction of any previous job definitions will be deprecated and removed in GitLab 12.0 or later.
Update your job definitions to use the new syntax and take advantage of all the new security features provided by GitLab.
Removal date: June 22, 2019
The System Info section in the admin panel
GitLab provides information about your GitLab instance in admin/system_info, but this information may be inaccurate.
We from the admin panel in GitLab 12.0 and recommend using .
Removal date: June 22, 2019.
Source: habr.com
