GitLab 11.10 with pipelines in the dashboard, pipelines for merged results, and multi-line suggestions in merge requests.
Convenient information about pipeline performance across different projects
GitLab continues to enhance the transparency of the DevOps lifecycle. In this release, a pipeline status overview has been added.
This is convenient, even if you are examining the pipeline of a single project, but especially helpful if , which is usually the case if you are using microservices and want to run a pipeline for testing and delivering code from different project repositories. Now you can see the performance of , no matter where they are executed.
Launching pipelines for merged results
Over time, the source and target branches may diverge, leading to a situation where they work fine individually but not together. Now you can . This way, you'll quickly notice errors that would only appear during frequent changes between branches, allowing you to fix pipeline issues faster and utilize your resources more effectively. .
Further optimization of collaboration
GitLab 11.10 introduced even more features for seamless collaboration and streamlined workflows. In we introduced suggestions for merge requests, where a reviewer could propose a single-line change in a comment, and it could be committed right from the comment thread. Our users liked this feature and requested its expansion. Now you can propose , specifying which lines to delete and which to add.
Thank you for your feedback and suggestions!
And that's not all...
This release has so many amazing features, such as , more thorough , and the ability to . Below are the details about each of them.
The most valuable player of the month () — Takuya Noguchi
This month’s MVP is Takuya Noguchi (). Takuya : fixing bugs, completing unfinished work in both the backend and frontend, and enhancing the user interface. Thank you!
Key Features of GitLab 11.10
Pipelines on the Dashboard
PREMIUM, ULTIMATE, SILVER, GOLD
The dashboard in GitLab displays information about projects across the entire GitLab instance. You can add individual projects one by one and choose which project interests you.
In this release, we added information about pipeline statuses on the dashboard. Developers can now see the operational status of pipelines across all relevant projects — in one interface.
Pipelines for Merged Results
PREMIUM, ULTIMATE, SILVER, GOLD
Over time, the source branch typically diverges from the target branch unless you continuously move changes between them. As a result, both the source and target branch pipelines may appear 'green' with no merge conflicts, but merging may fail due to incompatible changes.
When a merge request pipeline automatically creates a new link that contains the merged result of the source and target branches, we can run a pipeline on this link and ensure the overall result will function correctly.
If you are using merge request pipelines (in any capacity) and leveraging private GitLab runners version 11.8 or older, they need to be updated to avoid issues. . This does not affect users of public GitLab runners.
Proposing changes across multiple lines
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
When collaborating on merge requests, you often identify issues and suggest solutions. Since GitLab 11.6, we support for a single line.
In version 11.10, you can propose changes for multiple lines in the comments of a merge request diff, and any user with write permissions to the source branch can accept them with one click. This new feature helps avoid copy-pasting as in previous versions.
Labels in the Same Area
PREMIUM, ULTIMATE, SILVER, GOLD
With labels in the same area, teams can apply mutually exclusive labels (in the same area) to an issue, merge request, or epic in scenarios with custom fields or custom workflow states. They are configured using a special syntax with a colon in the label title.
Suppose you need a custom field in tasks to track the operating system of the platform your features are targeting. Each task should relate to only one platform. You can create labels platform::iOS, platform::Android, platform::Linux and others as necessary. If you apply such a label to a task, another existing label that starts with platform::.
Suppose you have labels workflow::development, workflow::review and workflow::deployed, indicating the workflow state in your team. If a task already has a label workflow::development, and a developer wants to move the task to the workflow::reviewstage, they simply apply a new label, and the old one (workflow::development) is automatically removed. This behavior already exists when you move tasks between label lists on the board that represents your team's workflow. Now, team members who do not work directly with the task board can change the workflow state directly within the tasks.
More thorough container registry cleanup
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
When using the container registry with CI pipelines, you send several separate changes to one tag. Due to the implementation of Docker distribution, the default behavior is to retain all changes in the system, but ultimately they occupy a lot of memory. If you use the parameter -m with registry-garbage-collect, you can quickly remove all previous changes and free up precious space.
Purchasing additional CI Runner minutes
BRONZE, SILVER, GOLD
Users with paid GitLab.com plans (Gold, Silver, Bronze) can now purchase additional CI Runner minutes. Previously, you had to stay within the quota provided by the plan. With this improvement, you can pre-purchase minutes beyond the quota to avoid interruptions due to pipeline stoppages.
Currently, 1000 minutes cost $8, and you can purchase as many as you need. Additional minutes will start to be consumed once you exhaust your monthly quota, and any remaining additional minutes will carry over to the next month. In , we want to add this feature to the free plans as well.
Composable Auto DevOps
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
With Auto DevOps, teams can transition to modern DevOps practices with minimal effort. Starting from GitLab 11.10, each job in Auto DevOps is provided as . Users can use in GitLab CI to include specific Auto DevOps stages while leveraging their custom file gitlab-ci.yml. This way, only the necessary jobs can be included, allowing you to benefit from upstream updates.
Automatic group member management on GitLab.com using SCIM
SILVER, GOLD
Previously, managing group memberships on GitLab.com had to be done manually. Now, you can use SAML SSO and manage memberships with SCIM to create, delete, and update users on GitLab.com.
This is especially useful for companies with a large number of users and centralized identity providers. Now you can have a single source of truth, such as Azure Active Directory, and users will be created and removed automatically through the identity provider rather than manually.
Logging into GitLab.com through a SAML provider
SILVER, GOLD
Previously, when using SAML SSO for groups, a user had to log in with GitLab credentials and the identity provider. Now, users can log in directly via SSO as a GitLab user linked to the configured group.
Users will not have to log in twice, making it easier for companies to use SAML SSO for GitLab.com.
Other improvements in GitLab 11.10
Child epic schema
ULTIMATE, GOLD
In the previous release, we added child epics (epics of epics) to make it easier for you to manage task distribution structure. Child epics are displayed on the parent epic page.
In this release, the child epic schema is displayed on the parent epic page, allowing teams to see the history of child epics and manage time dependencies.
Merge request tooltip screens
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
In this release, we are introducing informative screens that pop up when hovering over a merge request link. Previously, we only showed the merge request title, but now we also show the merge request status, CI pipeline status, and a short URL.
In future releases, we plan to add more important details, such as , and we'll also introduce tooltip screens for .
Filtering merge requests by target branches
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Git workflows for software release or delivery are often associated with several long-lived branches—for applying fixes to previous versions (for example, stable-11-9) or transitioning from quality assurance to production (for example, integration), but it can be difficult to find merge requests for these branches among numerous open merge requests.
The list of merge requests for projects and groups can now be filtered by the target branch of the merge request, making it easier to find what you need.
Thank you, Hiroyuki Sato ()!
Push and merge with a successful pipeline
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
If we're using the Trunk-based development method, we should avoid long-lived branches in favor of small, temporary branches with a single owner. Minor changes are often pushed directly to the target branch, but we risk breaking the build.
In this GitLab release, new push parameters for Git are supported to automatically open merge requests, set the target branch, and ensure merges with a successful pipeline from the command line during a push to the branch.
Improved integration with external monitoring dashboards
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab can interact with multiple Prometheus servers (at the environment, project, and ), but having multiple endpoints can complicate the system or may not be supported by standard monitoring dashboards. In this release, teams can use a single Prometheus API, significantly simplifying integration with services like Grafana.
Sorting Wiki pages by creation date
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
In the project Wiki, teams can share documentation and other important information alongside source code and issues. In this release, the list of pages in the Wiki can be sorted by creation date and title to quickly find recently created content.
Monitoring resources requested by the cluster
ULTIMATE, GOLD
GitLab helps monitor the Kubernetes cluster for development and production applications. Starting with this release, monitor resources requested by the cluster, such as CPU and memory, to catch potential issues before they become problematic.
Viewing load balancer metrics on the Grafana dashboard
CORE, STARTER, PREMIUM, ULTIMATE
It is very important to monitor the performance of your GitLab instance. Previously, we provided default dashboards through an embedded Grafana instance. Starting with this release, we have included additional dashboards for monitoring NGINX load balancers.
SAST for Elixir
ULTIMATE, GOLD
We continue to expand language support and deepen security checks. In this release, we have included security checks for projects in and projects created on .
Multiple queries on a single chart.
PREMIUM, ULTIMATE, SILVER, GOLD
In GitLab, you can create charts to visualize collected metrics. Often—for example, if you need to look at the maximum or average value of a metric—you want to display several values on one chart. Starting with this release, you have that capability.
DAST results on the group security dashboard.
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
We have added Dynamic Application Security Testing (DAST) results to the group security dashboard, alongside SAST, container scanning, and dependency scanning.
Adding metadata to the container scan report.
ULTIMATE, GOLD
In this release, the container scan report contains more metadata—we've added the affected component (Clair feature) to existing metadata: priority, identifier (linked to mitre.org), and affected level (e.g., debian:8).
Adding metric report types to merge requests.
PREMIUM, ULTIMATE, SILVER, GOLD
GitLab already provides several types of reports that can be included directly in merge requests: from and at the review stage to and at the protection stage.
And while these are important reports, basic information suitable for various scenarios is also needed. In GitLab 11.10, we provide metric reports directly in the merge request, which expects a simple key-value pair. This way, users can track changes over time, including custom metrics, and metric changes for a specific merge request. Memory usage, specialized load testing, and uptime statuses can be transformed into simple metrics that can be viewed directly in merge requests alongside other built-in reports.
Support for Maven multi-module projects for dependency scanning
ULTIMATE, GOLD
In this release, Maven multi-module projects support GitLab dependency scanning. Previously, if a submodule had a dependency on another submodule at the same level, it couldn't resolve loading from the central Maven repository. Now, a Maven multi-module project is created with two modules and a dependency between them. Dependencies among modules at the same level are now available in the local Maven repository to continue the build.
Users can change the cloning path in CI
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
By default, GitLab Runner clones the project to a unique nested path in $CI_BUILDS_DIR. However, for some projects, like Golang, the code needs to be cloned into a specific directory for it to be built.
In GitLab 11.10, we introduced the variable GIT_CLONE_PATH, which allows specifying the exact path where GitLab Runner clones the project before executing the job.
Simple masking of protected variables in logs
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab provides several ways to and of variables in GitLab CI/CD. However, variables may still intentionally or accidentally get into build logs.
GitLab takes risk management and auditing seriously and continues to add features to meet requirements. In GitLab 11.10, we introduced the ability to mask certain types of variables in job trace logs by adding a level of protection against accidentally including the content of these variables in logs. Additionally, GitLab now many built-in token variables.
Enabling and disabling Auto DevOps at the group level
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
With Auto DevOps in a GitLab.com project, you can easily engage in modern DevOps workflows—from build to delivery.
Starting from GitLab 11.10, you can enable or disable Auto DevOps for all projects in a group.
Simplified and improved license page
STARTER, PREMIUM, ULTIMATE
To make managing license keys easier and simpler, we redesigned the license page on the admin panel and highlighted the most important elements.
Update label selector for Kubernetes deployments
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Deployment panels display information about all Kubernetes deployments.
In this release, we changed the way labels are matched with deployments. Matches by app.example.com/app and app.example.com/env or app. This will help avoid conflicts during filtering and the risk of incorrect deployments related to the project.
Moreover, in GitLab version 12.0 we , and matching will only be possible by app.example.com/app and app.example.com/env.
Dynamically creating Kubernetes resources
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Kubernetes integration in GitLab allows the use of RBAC functionality through a service account and dedicated namespace for each GitLab project. Starting from this release, these resources will be created only when needed for deployment for maximum efficiency.
During Kubernetes deployment, GitLab CI will create these resources before deployment.
Group runners for clusters at the group level
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Group-level clusters now support the installation of GitLab Runner. Kubernetes runners at the group level are displayed for child projects as group runners marked with labels cluster and kubernetes.
Counter for Knative functions
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Functions deployed with , now show the number of incoming calls for each function. For this, Prometheus needs to be installed on the cluster where Knative is deployed.
Parameter control git clean for GitLab CI/CD jobs
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
By default, GitLab Runner executes git clean during the code unloading process when running a job in GitLab CI/CD. Starting from GitLab 11.10, users can control the parameters passed to the command git clean. This is convenient for teams with dedicated runners, as well as for teams that build projects from large monorepositories. Now they can manage the unloading process before the scripts are executed. The new variable GIT_CLEAN_FLAGS defaults to -ffdx and accepts all possible parameters for the command [git clean](https://git-scm.com/docs/git-clean).
External authorization in Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Protected environments may require an additional external authorization resource for project access. We have added support for an additional level of access control in and have received many requests to open this functionality in Core. We are pleased to present external authorization and an additional layer of security for Core instances, as this feature is needed by certain participants.
Ability to create projects in groups in Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
The Developer role can create projects in groups , and now this is possible in Core. Project creation is a key feature for productive work in GitLab, and with this function included in Core, instance participants can now more easily engage in something new.
GitLab Runner 11.10
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Today we released GitLab Runner 11.10! GitLab Runner is an open-source project used to run CI/CD jobs and send results back to GitLab.
The most interesting changes:
- .
- .
- .
- .
- .
The full list of changes can be found in the GitLab Runner changelog: .
Fix for the returned project_id in the blob search API in Elasticsearch
STARTER, PREMIUM, ULTIMATE
We fixed a bug in the blob search API in Elasticsearch that erroneously returned 0 for project_id. You will need to , to get the correct values project_id after installing this version of GitLab.
Omnibus Improvements
CORE, STARTER, PREMIUM, ULTIMATE
We made the following improvements to Omnibus in GitLab 11.10:
- GitLab 11.10 includes , , whose latest release includes a new integration catalog for easy data migration from Hipchat, and much more. This version includes , and we recommend upgrading.
- We , making it very easy to start monitoring the GitLab instance now.
- We added support for removing old container images from the Docker registry.
- We updated ca-certs to 2019-01-23.
Performance Improvements
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
We continue to enhance GitLab's performance with each release for GitLab instances of any size. Some improvements in GitLab 11.10 include:
- .
- .
- .
- .
- .
- .
- .
- .
Improvement of GitLab charts
CORE, STARTER, PREMIUM, ULTIMATE
We have made the following improvements to GitLab diagrams:
- .
Deprecated features
GitLab Geo will provide hashed storage in GitLab 12.0
GitLab Geo requires to mitigate competition 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.
Support for Ubuntu 14.04
GitLab 11.10 will be the last release with .
Canonical announced the end of standard support for Ubuntu 14.04 as of . We advise users to upgrade to a supported LTS version: Ubuntu 16.04 or Ubuntu 18.04.
Removal date: May 22, 2019.
Limit on the maximum number of pipelines created by a single push
Previously, GitLab created pipelines for HEAD for each branch in a push. This is convenient for developers who push multiple changes at once (for example, to a feature branch and to the develop).
However, when pushing a large repository with many active branches (e.g., for moving, mirroring, or branching), it is unnecessary to create a pipeline for each branch. Starting with GitLab 11.10, we create per push.
Removal date: May 22, 2019.
Outdated legacy paths for GitLab Runner code
Starting with GitLab 11.9, GitLab Runner uses of cloning/calling the repository. Currently, GitLab Runner will use the old method if the new one is not supported. For more details, see .
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 .
In version 11.3, GitLab Runner began supporting ; which led to new settings for . In , a table of changes and instructions for transitioning to the new configuration. For more details, see .
These paths will be unavailable in GitLab 12.0. As a user, you don’t need to change anything, just ensure that your GitLab instance is running version 11.9+ when updating 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 !
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 using new commands. This only affects users who . For more details, see .
Removal date: June 22, 2019.
Removal of the legacy git clean mechanism from GitLab Runner
In GitLab Runner 11.10 customize how the Runner executes the command git clean. Additionally, the new cleanup strategy removes the use of git reset and places the command git clean after the unload step.
Since this change in behavior may affect some users, we have prepared a parameter FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Setting this to true, it will restore the legacy cleanup strategy. More about using feature parameters in GitLab Runner can be found .
In GitLab Runner 12.0, we will remove support for the legacy cleanup strategy and the ability to restore it with a feature parameter. For more details, see .
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.
Changelog
Find all these changes in the changelog:
Installation
If you are setting up a new GitLab installation, visit .
Upgrade
Check out .
GitLab subscription plans
GitLab is available in two options: and .
: locally or on your preferred cloud platform.
- Core: for small teams, personal projects, or a trial version of GitLab for an unlimited period.
- Starter: for teams working in one office on multiple projects that need professional support.
- Premium: for distributed teams that need advanced features, high availability, and 24/7 support.
- Ultimate: for enterprises that require a robust strategy and implementation with improved security and compliance.
— GitLab.com: hosted, managed, and administered by GitLab with for individual developers and teams.
- Free: unlimited private repositories and an unlimited number of project participants. Closed projects have access to features at the Freelevel, while have access to features at the Gold.
- Bronze: for teams that need access to advanced workflow features.
- Silver: for teams that require more robust DevOps capabilities, compliance, and quick support.
- Gold: suitable for numerous CI/CD jobs. All open projects can use Gold features for free regardless of the plan.
Source: habr.com
