GitLab 10.7 released: Web IDE in open access and SAST reports for Go and C / C ++
Adding new functionality, reviewing changes, and code deployment are all standard workflows that developers face daily. With the release of this release, we simplify their implementation using our Web IDE, more flexible pipelines, additional security testing and much more.
Web IDE is now publicly available and open source
In GitLab, we want every participant to contribute to the workflow, regardless of whether he is a novice user, who is just getting acquainted with git and working on his first commit, or an experienced developer reviewing a whole set of changes. Local tasks such as setting up the development environment or switching between branches can complicate the development process. With our Web IDE, you can make changes to the files, make commits, review changes and preview Markdown directly from the browser. You can even open a diff of a merge-request with a visual display of the changes side by side. Web IDE is publicly available from version 10.7, we also open access to its source code .
Deployment Tokens
For any organization that works with containers , their registry is a key component of the infrastructure: it is a versioned repository that provides easy and secure access to container images. The usual use of a register is to provide images to an orchestrator, for example Kubernetes ( https://kubernetes.io/ ). It is important that this system always has access to the register, since the same Kubernetes pull-out container images during the initial deployment, with each restart of the hearth and with the addition of additional pods in the scaling process.
Previously, there were only two ways to get access to the register and repository. One of these is the CI work token , which provides temporary access for the duration of the work, and the other is the personal access token , which provides access to a specific user for an unlimited time. When using the work token, CI Kubernetes loses access upon completion of the work, so this option is not suitable for repetitive events, such as the start-up of pods and scaling. The use of personal access tokens also has disadvantages: either access must be tied to a specific user, or an additional account is required, for which a license is required.
To solve this problem, we created deployment tokens that provide long-lasting read permission. Using the deployment token, Kubernetes can receive all the necessary images as needed, without being tied to a specific user and without obtaining unnecessary access rights.
CI / CD Variable Flow Control
Service CI / CD is one of the main driving elements of the software development process. It performs many tasks: from basic ones, such as assembly, testing and deployment, to more creative ones. Given the range of tasks performed, it is important for users to be able to run certain jobs only on a specific requirement. GitLab CI / CD already provides a large set of settings for controlling the flow of execution , but there were some scenarios, such as nightly builds, that were not so easy to set up.
In GitLab 10.7, we added the ability to run jobs based on the values of certain variables . This will allow new scenarios to be executed, such as launching jobs related to a specific schedule or API trigger .
SAST for Go and C / C ++
Part of the Complete DevOps project is to provide first-class security tools. The Static Application Security Testing System (SAST) analyzes your source code for vulnerabilities and displays the result directly in the Merge Requests window. However, in order to conduct this analysis, SAST requires the support of a programming language in which you write. For this reason, we are adding Go and C / C ++ support for SAST.
This month's ( MVP ) is Rob Watson
Rob added a checkbox that allows HTTP connections to be redirected to HTTPS for GitLab Pages , which increases the security of the content.
Thanks, Rob! As a token of gratitude, we sent him a brand handmade sweaters, socks and tanuki with the symbols of GitLab.
Open source Web IDE (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
The new Web IDE simplifies and speeds up the addition of small fixes and work with feedback on merge-requests, since it eliminates the need for local storage of changes and switching branches.
With the Web IDE, you can make changes to files, preview Markdown, review changes, and commit directly from the browser. The Web IDE is available in the repository viewports and individual files, as well as in the Merge-Requests window - all this allows you to quickly respond to feedback or make small changes directly during the review code. When you open a merge request in the Web IDE, you can also view its diff before the commit, which allows you to see the overall picture of the changes in the merge request right in the IDE.
Initially, the Web IDE was added to GitLab Ultimate 10.4 , and from this release it goes public. We decided to make its source code open, because we believe that only joint work allows us to create such complex and subjective functionality as the IDE. In addition, it will allow more users to participate in the work on their favorite projects.
Deployment Tokens (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
There are situations in which it is necessary for a long time to provide read access to the repositories or Docker images loaded into the GitLab container register. Previously, you had to use personal access tokens (Personal Access Tokens - PAT), however, these tokens are tied to a specific user and his access rights.
The deployment tokens added in GitLab 10.7 solve this problem by providing a constant token associated with a specific project. Users can enable access to the repository or the register of containers, select this token and set expiration for it.
Deployment Token Documentation
Variable support for the keywords 'only' and 'except' (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab CI / CD allows you to set conditions for running a particular job using the keywords 'only' and 'except'. For example, you can allow the launch of a deployment operation only in the 'master' branch.
In GitLab 10.7, we have expanded the syntactic capabilities of such conditions, which allows the use of expressions with variables, in which the performance of the work depends on the presence of a particular environment variable or its value. For example, you can specify which jobs should be launched by changing the values of project variables. Or, you can limit the launch of a particular job only to those cases where the value of the variable GITLAB_USER_NAME matches the name of a specific user.
Variable support documentation
SAST for Go and C / C ++ (ULTIMATE, GOLD)
The Static Application Security Testing System (SAST) works only when the project uses a programming language supported by one of the GitLab tools. Therefore, in each release we add support for new languages.
In GitLab 10.7, we added support for Go and C / C ++, so now you can use automatic vulnerability testing for projects written in these languages. To connect this functionality, no additional actions are required - the language is automatically detected in runtime.
Other GitLab 10.7 Improvements
Comments in the epic (ULTIMATE, GOLD)
In this release, we continue to work on the introduction of portfolio management functionality into the epics. Now you can add comments to epics, and even create separate threads of epic discussions, the same as for tasks and Merge-Requests. Thanks to this, it became possible to hold discussions in the epic itself, at a higher level of abstraction, rather than using existing tasks for this or, even worse, creating new ones.
This functionality is also supported by the API .
Epic does not yet support todo and email alerts, but we are working on it .
Bulk adding text to all email messages (PREMIUM, ULTIMATE, SILVER, GOLD)
It is not uncommon for organizations for various reasons (from legal to technical) to add a disclaimer or some other text to all their email communications.
In this release, we added this feature: now GitLab administrators can enter arbitrary text in the mail settings. This text will be added to the end of all emails sent by GitLab.
Documentation for adding text to emails
Tasks of subgroups in group task boards (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Group task boards provide a single task management interface for several projects of the same group at once. This approach is useful for teams that work in different repositories (and therefore in various GitLab projects).
In previous versions of GitLab, only tasks of directly subsidiary projects of this group were added to the group board (only one level). Starting with this release, tasks of all projects of all subgroups of this group are added to the group board. So if you use a complex multi-level hierarchy of subgroups, this hierarchy will be supported by group task boards.
Filtering and adding tags for subgroups (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Working with subgroups is an important feature of GitLab, and we want to take a similar approach to using tags. Starting with this release, we have expanded the ability to add tags to tasks and merge-requests at various levels of subgroups.
In particular, it became possible to add group labels of a certain group to any of its child tasks and merge-requests. This means that a label created at a certain level of groups will be available for all subgroups at a lower level.
Since objects belonging to subgroups are displayed in task lists and merge-requests, we added filtering of these lists by group tags belonging to both child and parent groups (because all of them can now have such tags). In other words, you have the ability to filter by all possible labels of an object, regardless of its location in the hierarchy.
This approach to filtering is also available in group task boards, both in the filter window and in the board settings.
Project icons (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Many projects, such as GitLab CI / CD and shields.io, use badges to display build status and code quality. As a rule, badges are added to the project's readme.
Now you can enable the display of icons under the project description, as well as their display for all projects of the group.
Permissions to unprotect branches (PREMIUM, ULTIMATE, SILVER, GOLD)
The functionality of protected (protected) branches restricts permissions to push and merzh to certain branches, for example, you can disable pushing directly to master . However, users with a Master access level can unprotect branches, which allows them to bypass such bans. New restrictions on the removal of protection allow you to specify exactly which users and groups can remove protection from a particular branch.
At the moment, such restrictions can be set only through the API; we will add interface support in the next release . It is also likely that in future versions we will remove the Admin access level ( 60 ) and add restrictions for the Owner level as an alternative.
Task weight on task board cards (STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Previously, when working with the task board, to view the weight of a specific task, you had to click on its card — its weight was displayed in the side window. Now it is displayed on the card itself. Thanks to this innovation, you can at a glance assess the weight of all the tasks on the board and the amount of work needed to complete them. This is especially useful for methodologies like Agile .
GitLab Plugins (CORE, STARTER, PREMIUM, ULTIMATE)
Since GitLab is an open source project, everyone can complement it. But not all users want to immediately make their changes to the general access, they may first want to personally try what happened. Until now, this could only be done by launching a separate fork of the GitLab, which is rather hard to keep up to date.
Plugins allow you to respond to the GitLab system hooks using a script stored on the GitLab server - you can easily extend GitLab to your needs. For example, automatically configure your own protected branch rules when you create a new project.
Git HTTP (s) is always available for CI / CD (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab, you can use either SSH or HTTP (s) to access repositories. Sometimes GitLab administrators prefer to block access over HTTP (s) for security reasons. For example, blocking HTTP (s) will not allow users to reveal their login information when working through unsafe client settings. However, HTTP (s) blocking also prevents the GitLab Runner from cloning the repository, which is why CI / CD does not work as expected.
Starting with GitLab 10.7, clone / fetch requests from GitLab Runner will have access to the HTTP (s) protocol, even if such access is denied to users. From a security point of view, this is not the same thing, since GitLab Runner always uses OTP tokens that cannot be used to perform attacks.
Visibility and access control documentation
JSON Web Token OmniAuth support (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab uses OmniAuth to enable users to log in to GitLab using popular services such as Twitter or Google, as well as using standard OAuth2 identification tools. Gitlab 10.7 adds support for JSON Web Token (JWT) in OmniAuth.
JSON Web Token is a compact, stand-alone method for securely transferring information, often used to identify between different services.
JWT OmniAuth provisioning documentation
Automatic background scan of Geo copies (PREMIUM, ULTIMATE)
An automatic background copy check now takes place while Geo is running, to make sure the copy is consistent with the source. This is important when using Geo for disaster recovery: now in case of failures, you can confidently switch to backup — it is the same as the main GitLab instance.
Using heads and tags GitLab calculates a checksum for each Git repository and verifies that the checksum of the source instance coincides with that of the backup. Checks will be expanded in future releases and will also include downloads and keep-around links .
Background Check Geo Documentation
Creating projects in groups for Starter (STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Our model of access rights has become more flexible: now the administrator can enable in the settings an option that allows users with the Developer access level to create projects.
Previously, this functionality was only available to users of the GitLab Premium plan.
Project exports include LFS objects (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Exporting projects allows you to conveniently move projects (along with tasks, merge requests, tags, wiki pages, and downloads) between GitLab instances. Project exports now include LFS objects: you can move repositories with LFS objects using normal project exports.
Documentation on import and export projects
Dependency scanning has become independent functionality (ULTIMATE, GOLD)
Prior to this release, security checks for external dependencies and the libraries used by your application occurred along with SAST. Even taking into account the fact that these are closely related things, we decided that they should be divided into two independent functionalities.
GitLab 10.7 presents dependency scans as a separate, dedicated part of security reports that provide information about vulnerable libraries that are worth updating. Results will be available both in merge-requests and in the overview of the pipeline.
Documentation about dependency scanning
Special timeouts for runner (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
At the moment, GitLab determines the timing of the CI / CD work at the project level. If the job takes longer, it will automatically stop with an error report.
In GitLab 10.7, there is a new timeout setting on the runner, which applies to all the jobs it starts. This is especially useful for general runner in order to prevent potential abuses when the project sets long timeouts.
Documentation on special timeouts for runner
It is easier to find out the reason for the fall of CI / CD (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
When a CI / CD job crashes, users usually want to find out what happened and commit a fix, after which the work will be done as expected. Before this release, it was necessary to go into the details of the work and watch the logs.
To make debugging easier and faster, GitLab 10.7 introduces a new feature: the reason for the crash is indicated as part of the status, which can be viewed in its entirety by moving the cursor.
Documentation for reasons for the fall of the work
Ubuntu 18.04 Bionic support (CORE, STARTER, PREMIUM, ULTIMATE)
April 26, a new version of Ubuntu - Ubuntu 18.04 Bionic . GitLab is now available for her.
Installing GitLab on Ubuntu 18.04 Bionic
GitLab backup recovery enhancements (CORE, STARTER, PREMIUM, ULTIMATE)
GitLab 10.7 supports the restoration of user subdirectories. For example, if your registry is located at /var/mypath/gitlab/registry , the restore will work. Previously, the process tried to rename the existing directory to <name>.<timestamp> , for which there was no permission. Now it will create a temporary tmp folder in the restored directory and move all existing files there before restoring the backup.
Backup and Recovery Documentation
Automatic redirect to HTTPS in GitLab Pages (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab Pages can provide static websites via HTTP or HTTPS. HTTPS is usually preferable because it encrypts all traffic, protecting content as long as it is transmitted over the network.
In the case when both options are available, in GitLab 10.7, users can configure projects so that HTTP requests are automatically redirected to the corresponding URLs with the HTTPS protocol. This will increase security and ensure that data will not be transmitted in plain text.
Documentation for automatic redirection to HTTPS in GitLab Pages
Automatic renewal of GitLab Let's Encrypt certificate (CORE, STARTER, PREMIUM, ULTIMATE)
In GitLab 10.5, we have simplified HTTPS connectivity for GitLab instances through integration with Let's Encrypt .
With GitLab 10.7, we make this process even easier . We have automated the update process and removed the need to keep Let's Encrypt always on. All you need to do to connect HTTPS is to start your external_url with https:// and that's it!
Documentation for automatic update Let's Encrypt
GitLab cloud chart available for Core (alpha) (CORE, STARTER, PREMIUM, ULTIMATE)
With the introduction of support for object storage in terms of Core , the alpha version of the GitLab cloud native chart is now available without a license. This chart represents a more cloudy proprietary architecture with a container for each GitLab component and does not require shared storage. These changes will increase the flexibility, scalability and performance of GitLab at Kubernetes.
Backup and Recovery Documentation
Improvements in the environment metrics board (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Summary statistics appeared on the environment metrics board. It displays the average and maximum values of each series for a certain period of time. For example, you can now quickly find out the average response time for the last 8 hours in order to understand what users usually encounter.
Also, the total CPU and memory consumption is now displayed, which provides an understanding of how resources of a particular environment in a cluster are used.
Documentation about tracking metrics in the environment
GitLab Runner 10.7 (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
This release also released a new version of GitLab Runner - 10.7. GitLab Runner is an open source project that is used to run and send the results of your CI / CD back to GitLab.
The most important changes are:
- Added ability to define memory in Docker containers
- Improved health check services
- Returned Go to version 1.8.7
- Added support for the max_job_timeout parameter to the registration
A complete list of changes can be found in the CHANGELOG GitLab Runner .
Omnibus Improvements (CORE, STARTER, PREMIUM, ULTIMATE)
- GitLab Mattermost version 4.8.1 includes several platform improvements. This includes iOS endpoints, which allow users to upload files larger than 20 MB, and much more.
- Updated
ssl_ciphersdefault list for NGINX, except forECDHE-RSA-DES-CBC3-SHAandDES-CBC3-SHAto prevent Sweet32 . - redis_exporter updated 0.17.1.
Performance Improvements (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Among all the performance improvements of GitLab 10.7, we would like to separately mention:
- Merge Requests now load faster and with less load
- The Merge Requests change section now partially uses Vue to simplify the interface and improve performance.
- Reduced Redis use in Merge Requests
- The number of personal projects of the user is now cached
- API no longer executes request if project is invalid
- When viewing Atom group feeds, fewer requests are created.
- Identifiers created for tasks, Merge Requests, Milestone and Epic, are now atomic
Full list of performance changes in GitLab 10.7
Detailed release notes and instructions for upgrading / installing can be found in the original English post: GitLab 10.7 released for free and C / C ++ .
')
Source: https://habr.com/ru/post/354998/
All Articles