GitLab 10.5 released: integration with Let's Encrypt, Gemnasium dependency checks and external CI / CD files
In GitLab 10.5, we added the ability to easily encrypt GitLab traffic and scale pipeline management, improve application security, and much more.
Reduced GitLab secure deployment time
It’s impossible to talk about Internet security without mentioning the HTTPS protocol. Its use is mandatory in cases where the GitLab instance is open to the public. HTTPS provides two key benefits. First, it is encrypting incoming and outgoing traffic during interactions with the server, so that the user identification data and other important information are protected from interception. Secondly, it is the ability to confirm the identification of the site. Without such a check, there is a chance of a random login to the wrong site.
The advantages of HTTPS play a particularly important role for remote use or for users of mobile applications, since they often use an unprotected Wi-Fi connection, which increases the risk of data leakage or connecting to fraudulent sites.
However, despite all of the above benefits, setting up HTTPS and requesting certificates can be time and effort-intensive, in particular, with credit cards and key management. In GitLab 10.5, we added integration with Let's Encrypt , an automated, free and publicly available certification authority. Now SSL certificates can be obtained instantly with one option. Connecting Let's Encrypt for your GitLab instance guarantees encryption of traffic and confirmation of your site identification. Integration with Let's Encrypt is available in both the paid and free versions of GitLab.
Scaling control pipelines
In this release, we add in general uncomplicated functionality with great potential.
Using DevOps in a corporate environment poses certain challenges. Many of our largest customers have a DevOps team responsible for supplying CI / CD pipelines to a large number of development teams throughout the organization. Managing such processes is quite time-consuming, as there was previously no scalable way to supply configuration of conveyors. Because of this, you had to manually copy the code between the various projects .gitlab-ci.yml files. In addition to the overhead, this approach created the likelihood of errors. In addition, it was impossible to track that the testing and deployment processes are conducted stably for each repository.
Starting with GitLab 10.5, you have the option to include external files in the definition of the CI / CD pipeline . These files can be either local (contained in the same repository) or remote (accessible via HTTP / HTTPS). The inclusion of local files allows you to split the bulky .gitlab-ci.yml into modules that are easier to work with. Using remote files allows you to distribute these modules over thousands (potentially millions) of repositories. Now you have a simple and stable way to supply the configuration of conveyors.
Improved security testing using Gemnasium
Less than a month ago, GitLab acquired Gemnasium . As we promised, we immediately provide our users with advanced Gemnasium functionality for dependency checking. It often happens that after such acquisitions companies deliver innovations as separate add-ons. However, GitLab’s philosophy is to have a single application architecture that is designed in such a way that development, testing, security, and operations teams can work in parallel with the same data in the same interface. Therefore, we fully integrate the Gemnasium technology into GitLab CI / CD, significantly improving the testing functionality.
Thanks to advanced algorithms and an extended vulnerability database, results in JavaScript, Ruby and Python have been improved. Also added support for PHP and Java.
Do not miss the new features.
This article is about 26 improvements to GitLab (18 of which are available in the open source version). Full list of improvements can be found here . Further in the article we will talk about the key innovations in version 10.5.
( MVP ) of this month - Hiroyuki Sato
Hiroyuki contributes to the development of GitLab from the earliest days of the project’s existence, and this month it’s becoming the MVP for the third time (for the first time it happened in GitLab 5.1!). In version 10.5, he added the ability to view a merge request for a commit , which makes it easier to track changes and speeds up the development process.
Thanks again, Hiroyuki! Although we know that the inclusion of GitLab in the Hall of Fame is the best reward, we also send Hiroyuki handmade tanuki, socks and a GitLab T-shirt.
Instant SSL with Let's Encrypt for GitLab
Often, GitLab stores the source code of the project - intellectual property, the privacy of which must be protected. A fundamental step for this is the use of HTTPS to encrypt credentials and support site identification.
Previously, in order to connect to HTTPS in GitLab, it was necessary to perform a number of actions: create a certificate request, pay a certification authority, copy files to a GitLab server, and finally configure GitLab to use them.
At 10.5 we significantly simplified this process by integrating with Let's Encrypt . If your instance is available over the Internet via the HTTP protocol, then all that now needs to be done for an HTTPS connection is to assign letsencrypt['enable'] = true in the gitlab.rb file and reconfigure it. Done, HTTPS is connected to the main GitLab domain!
In future releases, Let's Encrypt will be enabled by default , and support for other GitLab elements such as Registry , Pages and Mattermost will also be added.
More information about integration with Let's Encrypt here.
Include external files in CI / CD pipeline definitions
CI / CD pipelines are defined in a YML file located in the project repository. It often happens that the same job definitions are used for many different projects. Also, there are frequent situations when existing snippets are simply copied from the documentation and examples.
In GitLab 10.5, it became possible to import external files into the main configuration using the new include keyword. These files can be either local (from the same repository) or remote (publicly accessible via HTTP / HTTPS). Good examples of work that can be reused in this way are security checks and deployment configurations.
Documentation for including external files
Gemnasium dependency checks
Recently, GitLab acquired Gemnasium , and we immediately began working together to integrate this remarkable technology into our testing functionality.
Thanks to the existing vulnerability databases and improved detection of new ones, in GitLab 10.5 it has become possible to receive extremely accurate reports on the security of dependencies of your application in the following languages:
- Ruby
- Java (Maven)
- Javascript (NPM)
- Python
- Php
If you already use Auto DevOps , then you do not need to change anything. If you copied the job description into your pipeline, update it to access the new functionality. More information on the page with an example .
Documentation on supported languages and security audit tools
Tracking additional performance metrics in the browser
In GitLab 10.3, we added performance testing in the browser , with which you can quickly assess the impact of a merge request on performance. In this release, we analyze three additional metrics: the speed index , the size of the transfer and the number of requests.
We also added the ability to save the entire report sitespeed.io as an artifact, which provides easy access to a large amount of performance and debug data. If you use Auto DevOps , such reports will be saved automatically.
More information about browser performance testing here.
Git LFS 2 blocking support
Lock support has been added to Git LFS 2.0.0 . This functionality is now supported in GitLab, so you can block LFS files using the Git LFS client. Locked files are easily recognized by the corresponding icon.
Support for blocking any file or directory was added to GitLab Premium 8.9. With it, you can lock files through the GitLab interface. In GitLab Premium 10.5, we integrated Git LFS lock with GitLab lock.
More info on using git lfs here
Other improvements in GitLab 10.5
View epic in roadmap mode
In this release, we introduce the first iteration of roadmaps. Road maps allow you to simultaneously view several epics of one group (or even subgroups) at once with ordering by time. Now you can easily see when the epics begin and end relative to each other.
This innovation simplifies planning and tracking progress over time, and also clearly demonstrates overlapping workflows. For example, you want to launch a new feature of your product in the second quarter of 2018 and plan to conduct an appropriate marketing campaign. In this case, you will create one epic to work on functionality and another for marketing. In roadmap mode, both of these epics will be displayed simultaneously, which will simplify control over the time they start and end.
Dynamic management of secret variables
Secret variables are used to configure the CI / CD pipelines so that sensitive information is hidden from outside access. Users with the Master access level can define them in the CI / CD> Settings menu, but with this approach you can define variables only one by one.
In GitLab 10.5, we added the dynamic management of secret variables with the support of adding several variables at the same time, which simplifies working with them.
Definition of domain Auto DevOps at the instance level
Auto DevOps can automatically deploy your application to a Kubernetes cluster, but to access it you must provide the domain name associated with the public IP address of this cluster.
Starting with GitLab 10.5, you can define the domain name at the instance level and use it for the entire organization: it will be used automatically for any project in which the domain name is not specified.
Auto DevOps Base Domain Documentation
GitLab group migration
Now you can transfer entire GitLab groups from one to another, which simplifies the process of structuring groups and subgroups.
Ingress objects configured for Prometheus metrics
Ingress objects are now configured for Prometheus metrics, which makes it easier to track the following system metrics: latency, throughput, and error rate.
More information on deploying Ingress to Kubernetes here.
Additional approval of Merge Requests
We have simplified the logic of approval of merge requests: now it is even easier to configure and use permissions.
In particular, it is now possible to approve a merge request, even if the required number of statements has already been collected. Reviewers are no longer dependent on each other and can approve merge-requests when it is convenient for them. This approach encourages more users to participate in the code review process.
However, if the workflow requires it, you can manually set the number of required statements in accordance with the reviewers you choose.
As before, previously submitted statements can be deleted.
Merge Requests Approval Documentation
Display of tasks of all subgroups on the group tasks page
Now it became possible to display the tasks of all subgroups on the tasks page of their common group. This is very useful in cases where the hierarchy of subgroups forms a tree of several levels, and you need to view all of its tasks in one place. Examples of such situations can be teams with microservices distributed over many projects and groups, or organizations with a complex command hierarchy structure.
Exactly the same changes were made for the Merge-Requests page.
Color Icons in GitLab Flavored Markdown
GitLab Flavored Markdown (GFM) now supports color icons. Simply enter the appropriate color code in any place where GFM is supported (for example, descriptions and comments of tasks and Merge Requests), and GitLab will create a color icon in this place. This innovation will be especially useful for designers and front-end developers, since it will simplify working together on designs that contain different colors without having to leave GitLab.
Thanks to @thetonyrom and @raviolicode for their contributions!
GitLab Flavored Markdown Documentation
Push to create a project
Now when you push the repository to a project with a non-existent name (in your personal namespace), a private project with that name will be automatically created. Thanks to this, the creation of projects will be even faster!
More information on creating projects here.
Disaster recovery with a single secondary base is now shared
Disaster recovery functionality uses Geo replication to quickly navigate to another site with minimal effort in the event of an emergency. Emergency transition in configurations with a single secondary base is now publicly available.
Disaster recovery documentation
Menu search and filter epic
In this release, we added an epic search and filter menu to the page. This is the same search that is used throughout GitLab for tasks and merge requests. In this release, it is possible to filter the epic by the author, as well as search by titles and descriptions of epics. Additionally, epic can be sorted by date of creation or last update.
This makes it possible to take advantage of the lists to which you are probably already used to working with tasks and merge-requests. With the help of search and filtering, it will be easier for you to manage exactly those epics that you need. In the future, we plan to add additional filters - and begin by filtering by tags .
Sustainable deployment of public projects
Auto DevOps (currently available in beta) can automatically deploy your application to the Kubernetes cluster. However, this process may stop if the cluster needs to restart the scams - for example, if someone moved them and the original image cannot be found in the cache.
Starting from GitLab 10.5, public projects automatically set up a cluster so that it has access to the GitLab Container Registry even after the deployment pipeline ends, which will make your applications environment more stable.
Learn more about Auto DevOps Beta
Opportunity for developers to create projects in groups
With each release, we improve the flexibility of the GitLab access model: a setting is now available to the group or server administrators that allow users with the Developer role to create projects.
Read more in the access level documentation for creating a project.
Easy integration of Prometheus into Kubernetes
In GitLab 10.4, we added the ability to deploy Prometheus to the Kubernetes cluster connected to it with one click. In this release, we have moved on: we have done the integration of the project with Prometheus automatic.
GitLab uses the Kubernetes API to query the deployed Prometheus server, and this server does not need to be open for access from outside the cluster.
More information on application control with Prometheus
Global search API
We have added global search support to the GitLab API. In essence, this is the same global search from the GitLab web interface, only wrapped in an API - to allow external systems to take advantage of this functionality.
This will allow teams to create custom workflows — for example, look for something in the files and send statistics on the results.
The API works regardless of whether you have Elasticsearch (available only for GitLab Starter and above).
For details, see the global search API documentation.
Label List Page Redesign
We have simplified the label list page design, and now it will be easier for you to understand and manage each label. We also aligned the icons with our new design and regrouped references to tasks and merge-requests for each specific label - they now take up less space in width, which makes it easier to work with them.
See the label documentation for details.
Transition to linked merge requests from the commit page
Links to merge-requisitions related to the commit are now displayed directly on the commit page. This is useful when you look at the history of the commit repository and want to know the general purpose and technical context of the commit. Now you can easily go to the merge-request that generated the commit directly from the page of this commit. From the merge-request, in turn, you will see all previous discussions; and if a task was associated with it (for example, using the task closing mechanism , you can even go back to it to see its purpose.
Thank you for this feature @hiroponz .
Documentation of the transition to related merge requests from the commit page
Localization improvements
We continue to work on the localization of GitLab: in this version we externalized the lines in the task menu and merge-requests, on the repository graphs page and repository diagrams. The opportunity is available to any member of our translator community. If you want to join the GitLab translation, we ’ll be happy .
Beta version of hashed storage
Hashed storage is a new type of storage behavior that appeared in version 10.0. Instead of associating the project URL with the folder structure in which the repository will be stored on disk, we associate a hash based on the project identifier. This makes the folder structure unchanged, which helps to get rid of the additional requirements for state synchronization between the URL and the disk structure. This means that you can rename a group, user or project by a single transaction in the database - instantly.
Learn more in the hashed vault documentation.
Omnibus Improvements
- In GitLab Mattermost 4.6 , the download speed of the channel has decreased, and the corresponding section 508 has been enhanced (Section 508)
- Chef has been updated to 12.21.31.
- Chef Omnibus updated to 5.6.3.
- Added SELinux rules to quickly search for SSH keys .
For more information, see the Omnibus GitLab documentation.
GitLab Runner 10.5
Also in this release we release the next version of GitLab Runner - 10.5. GitLab Runner is an open source project used to run CI / CD and send the results back to GitLab.
Most important changes:
- Fixed compatibility with Git version 1.7.1
- When evaluating TLS connections, the pool of operating system certificates is now always loaded.
- No volume is added / cache, if the user has already provided it in the register gitlab-runner
For a complete list of changes, go to CHANGELOG GitLab Runner .
GitLab 10.5, :
release notes / : GitLab 10.5 released with Let's Encrypt integration, Gemnasium dependency checks, and CI/CD external files .
')
Source: https://habr.com/ru/post/350660/
All Articles