We are pleased to present you a new version of GitLab with many innovations and improvements! In this release, we have improved release automation, publicized previously paid functionality, accelerated the fixing of security vulnerabilities, and much more.
More confidence when deploying
The release of new functionality is always fraught with excitement, because even with the most stringent testing there is a risk of unforeseen complications. Our new feature Incremental Rollouts allows you to deploy code only for a specific subset of users. Now, instead of rolling out updates for all users at once, you can gradually increase the number of Kubernetes pods that are being deployed. In case of any complications, you can roll back the changes before they affect the entire user base. This innovation provides an additional level of user protection against unforeseen errors, ideally allowing you to deploy more frequently.
Mirroring the pushes is now publicly available.
Initially, pushing mirroring was available only for a paid subscription, however, since its release, this functionality has been one of the most sought after by users - many have asked for it to be shared. We take these issues seriously and believe that finding the perfect balance between paid and publicly available functionality is one of the key areas of project management policy . Therefore, starting with this release, pushing mirroring goes into open access .
Thanks to this, users of GitLab Core have new opportunities associated with, among other things, freelancing development and migration. Freelancers can now mirror any client repository, and users migrating to GitLab from other git repositories will be able to use the mirroring features to simplify the migration process.
Whenever possible, we strive to bring open-source functionality, both to attract new users of GitLab, and to increase the number of people involved in the development of open source software .
Acceleration of work with vulnerabilities
It is almost impossible to track vulnerabilities in code without any automation, so GitLab includes several built-in security systems, such as SAST , DAST , and container and dependency scanning. In this release, we continue to work in this direction.
When a vulnerability is discovered, you need to either fix it or ignore it in the event of a false positive response. Our new interactive security reports allow you to take the appropriate action directly from the report: you can either reject the vulnerability or create a task to fix it. This functionality simplifies the process of working with vulnerabilities and, as a result, accelerates the release of secure code.
Waiting for your answer!
We look forward to your reaction to the innovations of this release - what did you like? What should we improve? We will read with interest your comments on the original article and continue to work on improving GitLab.
Thank you for your participation!
Alexis added a very useful opportunity to create common CI Runners for groups . Users have requested this functionality for more than a year, and the contribution of Alexis has finally allowed to put it into practice. Now it’s much easier to manage runners of a certain group of projects.
Thank you, Alexis! As a token of gratitude, we sent him a brand handmade sweaters, socks and tanuki with the symbols of GitLab.
Incremental Deployment (PREMIUM, ULTIMATE, SILVER, GOLD)
When making major changes to your application, it is reasonable to deploy the version to a small subgroup of users in order to get feedback and detect possible problems. After that, you can consistently increase the percentage of users for whom you are deploying, until the new version completely replaces the previous one. Thus, if problems are detected at some stage, the product’s rollback will affect fewer users.
In GitLab 10.8, we add the ability to incrementally deploy code to 10, 25, 50 and 100 percent of your pods. You can also use this approach in Auto DevOps using the INCREMENTAL_ROLLOUT_ENABLED environment INCREMENTAL_ROLLOUT_ENABLED .
Incremental Deployment Documentation
Mirroring the pushes is now in the public domain (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Mirroring repositories allows you to copy Git repositories from one location to another. This makes it easy to work with multiple GitLab instances: for example, you can mirror the results of your team’s work to your clients' personal instance. Mirroring the push also simplifies moving a project to GitLab from other repositories, and the original repository from which the move is made remains relevant.
Earlier mirroring of push was available in GitLab Starter, and now in Core.
Mirroring documentation
Interactive Feedback in Security Reports (alpha version) (ULTIMATE, GOLD)
Security reports help you identify potential vulnerabilities in your software, after which you can take steps to fix them.
Starting from GitLab 10.8, you can create vulnerability remediation tasks right from the security report window. You can also reject a specific vulnerability in case of false positives. Your feedback is displayed directly in the report.
Security Reporting Documentation
Fuzzy file search for Web IDE (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
We added a fuzzy search for files in the Web IDE in order to simplify navigation for large projects. A fuzzy search is available by using the Cmd + p / Ctrl + p key combination.
Previously, you had to directly browse the project file tree to find a specific file.
Web IDE documentation
Commit individual files to a Web IDE (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
We added the ability to add (stage) individual files to a commit in the Web IDE, which allows you to commit small-scale commits. The changes are added to the corresponding list of unstaged changes, after which you can select the necessary files from this list and add them to the staged changes list — these files will become part of the next commit.
Web IDE documentation
Task schedules for groups (PREMIUM, ULTIMATE, SILVER, GOLD)
Task schedules are used in many projects to track the progress of a specific milestone. Since more and more teams are using division into groups and subgroups, we received many requests to add such graphs at the group level.
In this release, we add task schedules for group milestones. These graphs function in exactly the same way as the project schedules: they show the progress of all the tasks associated with Milestone, which provides a visual demonstration of the workflow. Using these graphs, you can estimate the likelihood of work being completed on time and make the necessary changes to the work.
By analogy with project schedules for performing tasks, schedules for groups take into account both the number of tasks and their weight. In addition, group schedules take into account the tasks associated with mylustone for all subgroups of the respective group.
Documentation of task schedules
Prometheus metrics are shared, enabled by default (CORE, STARTER, PREMIUM, ULTIMATE)
GitLab is often a key element of the software delivery cycle, so it is important to be confident in its stable and correct operation. In previous releases, we added Prometheus metrics for Redis and Postgres dependencies, as well as several experimental metrics in version 9.3 . Since then, we have covered with metrics some more parts of our code base, as well as reduced the negative impact of collecting metrics on performance. Now we use these metrics to monitor the GitLab.com service.
As a consequence of past innovations, we are launching monitoring of Prometheus to the public (GA, general availability) starting from version 10.8. For all new installations of GitLab monitoring will be enabled by default. We also released a trial version of the Grafana dashboard for visual visualization of metrics.
Prometheus monitoring documentation in GitLab
Other GitLab 10.8 Improvements
Confirmation of usage policy updates (CORE, STARTER, PREMIUM, ULTIMATE)
GitLab is preparing to introduce a GDPR and, as part of this process, we asked our users to review and confirm the updated Terms of Use. Instead of using this functionality once and forgetting about it, we decided to add it to GitLab so that users can use this feature in the future.
When this feature is enabled by the administrator of the instance, users will be required to review the Terms of Use and agree with them before continuing to work with GitLab. Until the user confirms this message, his access to GitLab via the web, API and Git will be blocked.
The message with the Terms of Use can be completely changed in the admin settings. Also, since this message is based on the GitLab-flavored Markdown , it may even contain links to other pages.
All confirmations from users are stored in the database, so you can use this information in the future.
Documentation on the confirmation of usage policy updates
Search and filter menu by road map epic (ULTIMATE, GOLD)
The search and filtering menu is a very useful part of the interface, familiar to users and used throughout GitLab. We decided to use this functionality to search and filter road map epic (roadmap) when viewing it.
In this release, you will be able to filter the epic by author and label in the roadmap view. In addition, you can search for epic by name and description. This will allow users to find epic related to them and their teams and bookmark links to save search settings.
Roadmap documentation
API discussions (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Discussions (comment threads) appear in many parts of the GitLab web interface: in tasks, merge requests, epics, snippets and commits. In this release, we have expanded the capabilities of the API, so that you can access and manage discussions directly through the GitLab API, which will make your workflows even more flexible.
API discussion documentation
SAST for PHP and Java Gradle (ULTIMATE, GOLD)
Static application security testing (SAST) is effective only when your project uses a programming language supported by one of the GitLab tools. That is why we are increasing the number of these languages with each release, adding the most popular ones.
In GitLab 10.8, projects written in PHP and Java with Gradle can be automatically checked for security vulnerabilities. To do this, you do not even need to determine the language - it is automatically detected in runtime.
SAST documentation
Defining variables for manual conveyors (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
It is often necessary to perform a single CI run with one-time settings to test a specific use case. For example, we can temporarily apply a specific deployment strategy or exclude a specific step from the application building process.
GitLab 10.8 offers the ability to define special one-time variables when starting the conveyor manually. You will not need to change the variables for the entire project in order to perform a single specific launch, thanks to which it will be much easier to perform non-standard tests with your own settings.
Documentation on starting pipelines
Merge commits in a merge request widget (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
We continue to work on small GitLab features that are important when using it. This change is a good example. If you use merge commits in your project, a link to merge commit will appear in the merge request widget immediately after merge. This link will take you directly to the merge commit.
For many workflows, it will be helpful to be able to go straight to the merge commit. For example, some teams transfer these merge commits to release branches or mark them with tags for testing or deployment to production. With this change, it will be easier for you to find out if the merge-request is part of the branch that you are going to deploy.
Merge Requests Documentation
System notes for adding task weight (STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
The weight of the task allows the GitLab task to match a specific numerical value indicating its volume. In particular, teams use task weights to plan development when working on Agile or on other methodologies based on agile development. In this release, we added system notes that appear every time you add or change task weights. This will help team members track changes to evaluate work, as well as simply find out when the first assessment was made.
Task weights documentation
Task weight and lock status in CSV export (STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
In this release, we added task weight and lock status to the export of CSV. This gives you even more information about the tasks so that you can conduct any type of analysis and workflow outside GitLab.
CSV export documentation
GitLab Merges Requests to the Jira Development Panel (PREMIUM, ULTIMATE, SILVER, GOLD)
In this release, we have improved the integration with the Jira Development Panel: now it includes the GitLab request. This means that if you use special integration , in the sidebar of the associated Jira task, in addition to the commits and Gitlab branches, merge requests will also be displayed.
Please note that in the Jira interface, merge requests are called “pull requests”.
Documentation on integration with the GitLab Jira Development Panel
Email Notifications for Epic Comments (ULTIMATE, GOLD)
In the previous release, we presented comment threads for epics. In this release, we made collaboration on epics even more similar to the rest of GitLab — by adding email notifications. As before, in tasks and merge-requests, you will receive notifications by email (specified by you in the GitLab settings) after corresponding activity in the epic. For example, when a member of the team mentions you in the description of the epic or comments to it, you will receive a notification if you have configured your notifications for a group of this epic to the Participate level or higher.
Epic Documentation
Improved display of long commit descriptions (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A good description of a commit that explains why a change was needed helps to make small atomic commits and makes it easier to read the commit logs for the rest of the team. We improved the display of long descriptions, so reading them has become even easier!
Support for built-in snippets (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Snippets are useful for discussing parts of the code. Now you can embed public snippets into your website. This is very helpful in documenting, supplementing a blog post with code examples or on a personal website. Thanks for this opportunity Haseeb .
Documentation for support for embedded snippets
API for project languages (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Using the new API for languages you can collect statistics on the project languages. This can be useful for reporting or research — for example, understanding which programming languages are most commonly used in your organization or in an open source project on GitLab.com. Thank you, Roger , for your contribution!
API documentation for project languages
GitLab Runner for groups (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab Runners have two types of settings: for the whole instance (shared) or at the project level (specific). However, sometimes there is a need to provide a set of Runners to an entire group of projects, without giving anyone access to them from outside. At GitLab.com, for example, this works well due to direct communication between groups and organizations.
Starting from GitLab 10.8, you can connect your GitLab Runner with a specific group - and each project of this group will receive CI / CD capabilities without any additional settings. And new projects will receive all the benefits of group Runner-s immediately after creation. For this feature, thanks to Alexis .
GitLab Runners Configuration Documentation
Support for the test environment policy for Auto DevOps (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Prior to this release, Auto DevOps by default used a continuous deployment model: the push to production automatically occurred every time the pipeline was launched in the master branch. This is very useful, but sometimes you need to use an additional test environment to complete the application or the availability of the production environment. Only after passing all the checks on it can you manually launch the deployment in production.
The Auto DevOps template has previously supported this feature, but it was not enabled by default. If someone wanted to use the run through the test environment, it was necessary to separately create the .gitlab-ci.yml .
Starting in GitLab 10.8, Auto DevOps templates allow users to turn on staging using an environment variable. You can specify STAGING_ENABLED for the whole group, for one project or even for a specific launch. Deploying to production will need to be started manually - and you can do it at the right time.
Auto DevOps Deployment Policy Documentation
Project templates now work with Auto DevOps (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab, you can easily get started on a project with a specific language: just use templates. This will allow you to quickly launch a new application and then customize it to your needs.
GitLab 10.8 includes enhanced versions of Rails, Spring, and Express templates, so you can use all the features of Auto DevOps when creating new projects. Using these improved templates, you can go from idea to production in minutes.
Documentation on creating project-based templates
Geo Improvements (PREMIUM, ULTIMATE, SILVER, GOLD)
- Geo comes with Git 2.16.3, which will significantly reduce the synchronization time of repositories with a large number of links.
- After the initial cloning of the repository, the secondary Geo node will repack (
git pack-objects ) to free up disk space. It will also perform garbage collection regularly ( git gc ). - When the checks of the repository are enabled, Geo will periodically run
git fsck on each repository of the secondary node. - Improved metrics Geo Prometheus: it became easier to find repositories with incompatible checksums.
Geo Documentation
Detailed release notes and instructions for updating / installing can be found in the original English-language post: GitLab 10.8 released with incremental rollouts, plus open source push mirroring .
Rishavant and sgnl_05 worked on translation from English.