GitLab 10.0 released with Auto DevOps and Group Issue Boards
GitLab 10.0 Released with Auto DevOps,Group Issue Boards, New Navigation, and much more!
From the formulation of an idea to executing and monitoring it in production, DevOps establishes
a culture and environment where developing, testing, and releasing software can happen quickly, frequently,
and more reliably.
GitLab 10.0 delivers a hands-free
DevOps environment with the introduction of Auto DevOps, allowing your team to easily configure and adopt
modern development practices in your workflow. Not only that, there's new navigation and a new way of collaborating across groups.
With every monthly release of GitLab, we introduce new capabilities and improve our existing features. GitLab 10.0 is no exception and includes numerous new additions, such as the ability to automatically resolve outdated merge request discussions, improvements to subgroups, and an API for Wiki thanks to a contribution from our open source community.
GitLab's powerful issue management capabilities keep getting better with every release. Filtering and searching issues across groups has been vastly improved, our updated UX makes moving issues easier to discover and can be automated through quick action commands. GitLab Enterprise Edition Premium customers using JIRA can now see commits and branches in JIRA's development panel.
Security and performance continues to improve. Administrators can now restrict SSH access through technology and key length. LDAP Group Sync can be automated through our API and can now lock down External Users at point of login as well. Performance continues to get faster, improving page loading speeds, the speed of creating projects and performing commits, and reduced memory usage.
Once again, we’ve had an incredible number of contributions
from the community, illustrating the power of open source software and its benefit to GitLab and
all of our users and customers.
Hiroyuki has provided numerous contributions
in GitLab 10.0, including performance improvements, enhancing searching and filtering issues and merge requests,
as well as one of our favorite features of being able to filter issues by your own reactions so
you can see what you’ve liked (or not!).
Thank you to everyone for your contributions, and a special thank you to Hiroyuki for such
amazing work.
Auto DevOps brings DevOps best practices to your project by automatically
configuring your build, test, code quality assurance, review apps, deployment,
and monitoring in a single environment. In GitLab 10.0, we
have introduced out-of-the-box templates to quickly set up an end-to-end DevOps
lifecycle, built on top of GitLab CI/CD.
As it stands, GitLab offers a single environment where a code change can not only initiate a build,
but deploy a Review App to preview your changes from
within each merge request. During the review process GitLab’s recently introduced ability to measure
Code Quality
ensures changes improve the overall quality of your software.
After code review, GitLab’s deployment capabilities easily allow you to deploy to
canary or production environments, as well as using GitLab Auto Deploy
to deploy straight to Google Cloud. Post-deployment metrics with
GitLab Auto Monitoring
provide response and system metrics to make sure newly deployed code is performant.
Now, GitLab 10.0 brings this entire lifecycle together in an automated way, allowing
you to go from idea to production in the blink of an eye with GitLab Auto Devops.
Auto DevOps
automatically detects, builds, tests, deploys, and monitors applications.
Leveraging Herokuish, it supports
all languages and frameworks available through Heroku buildpacks, such as Ruby, Rails,
Node, PHP, Python, and Java, as well as the ability to customize your own buildpacks.
Read the quick start guide
to begin right now.
Auto DevOps is currently in Beta and is not recommended for production use just yet.
Note: GitLab is not affiliated with Heroku or Glider Labs.
Many teams work as a GitLab group, with work spanning many projects in that group.
For example, many organizations are moving toward or have already adopted a microservices
architecture where each microservice is one code repository (housed in one GitLab project).
This means a team may naturally be working across multiple projects, making it extremely helpful
to manage issues across all those projects together.
With this release we are proud to ship our
most requested feature,
GitLab’s Group-level Issue Boards!
Now you can manage all issues across all projects within a group single and concentrated
view. Lists, labels, and milestones are all managed at the group level, allowing you to
focus on the group.
In GitLab 10.0 we are excited to unveil our new user experience, making it
much easier to navigate GitLab!
For the last few months, we have been testing out
a new way to navigate through GitLab. Based on feedback and user testing, we found
that people had a few problems with the existing navigation. Understanding
exactly which group or project you were currently viewing was often not
obvious, switching between different areas of GitLab was cumbersome and
there were a lot of inconsistencies with spacing and hierarchy that caused
confusion.
GitLab 10.0 introduces a more consistent navigation experience. The colored
top bar represents all global and personal aspects of GitLab – your groups,
projects, issues, merge requests, todos and personal information. The new left
navigation is contextual to the group or project you are viewing and also allows
quicker navigation between areas of the project, with pull-out menus saving you
clicks and page loads.
As an additional bonus, we’ve also brought back the ability to personalize your
experience, allowing you to change the color theme of GitLab because, well, not
everyone loves purple like we do!
When running sensitive jobs in CI/CD pipelines, for example deployments
to production environments, you want to be sure that nobody can access credential
information or private configuration options.
In order to avoid any data leakage, you can set the protected flag for a
specific GitLab Runner, so only jobs running on
protected branches
are picked up.
With thanks to our community contributor Corey Hinshaw
GitLab 10.0 now allows administrators to add restrictions on SSH keys.
This functionality allows administrators to restrict not only the type of
SSH keys that may be used, but also the minimal key length, giving you a more
secure way to manage your GitLab SSH access environment.
You can now use the GitLab API to work with wiki pages! With the additions
to the API, it is possible to get a list of all wiki pages, get a particular page,
create a new wiki page, as well as edit and delete pages, providing a great way
to programmatically access GitLab’s wiki functionality.
Many thanks to our community contributor, Vitaliy Klachkov for adding this functionality.
We’re also releasing GitLab Runner 10.0 today!
GitLab Runner is the open source project that is used to run your CI/CD jobs
and send the results back to GitLab.
During the initial registration of a new GitLab Runner,
you are asked if you want to lock it to the project for which you are providing the token.
Before GitLab 10.0, the default choice was false, but it was not clear that this allows any Master
of the project to enable the Runner also for other projects, and this might be a security risk.
With GitLab 10.0, the default choice is now true, so the Runner cannot be easily assigned to other projects.
This behavior can be changed later in the Runner settings, if there is the need. It can be also set
during registration manually (for interactive mode) or with the --locked=false option (for
non-interactive mode).
One of GitLab’s many distinguishing features is the granularity of permissions
and access to project capabilities.
In GitLab 10.0 we have simplified the user interface, allowing you to maintain
precise control of your project visibility, features and permissions, but doing so
in an easy-to-use and beautiful interface.
In GitLab 9.0
we released subgroups, giving you more flexibility in how you organize
projects and groups inside of GitLab. If you haven’t tried them out before,
you can find out more about subgroups in our documentation.
We’ve now added the ability to allow owners to create subgroups if group creation
has been restricted, making it easier for delegated users to manage the group
structure of GitLab.
Access GitLab Commits and Branches in JIRA Development Panel
Many GitLab users are also JIRA users. With this release, we are significantly
improving our JIRA integration by introducing linked commits and branches in a JIRA
issue’s development panel.
As you are interacting with a JIRA issue, you can now quickly click through to associated
GitLab commits or branches, further tightening the GitLab-JIRA integration.
We have now included time tracking information (time estimate and time spent) in the
existing issues CSV export functionality. This allows roles such as team leads or
managers to manage time tracking information easily in issues using spreadsheets.
Throughout GitLab, when you are filtering issues and merge requests, you
can now filter by reactions you have added. You can use this as a generalized
bookmarking feature. Just react to issues and merge requests by awarding
different emoji, and now you access those objects quickly by filtering on them.
There is now a move issue quick action to speed up your workflows even more.
So you can now type comments, and perform yet another action (moving an issue),
all within the comment box itself.
The environment monitoring dashboard has been significantly improved, with an improved look and feel as well as support for multiple series in a single chart.
This provides a deeper-level insight into performance as well as easy comparisons. For example, an application’s throughput can now be broken out by HTTP response type,
providing a single chart for both successful and failed request rates, as well as potential missing pages.
GitLab’s LDAP Group Sync is now available via API, allowing you to programmatically
request a sync event. This means that any group automation such as creation of groups
performed via the API can immediately be programmatically synchronized to LDAP with one
simple API call.
LDAP Config “verify_certificates” Defaults to Secure
The LDAP config option verify_certificates now defaults to true for security.
This option was added in 9.4.2 but defaulted to false for backwards-compatibility.
Installations that are using start_tls or simple_tls for the encryption
parameter and that unknowingly do not have SSL configured properly between the
LDAP server and the GitLab server, may break if the LDAP server’s SSL
certificate cannot be verified by the GitLab server.
Installation of GitLab is now easier and faster than ever! GitLab 10 adds support for specifying the GitLab URL
directly when installing the package. When specified, GitLab will automatically be reconfigured with the
URL and started, removing two steps from the installation process.
GitLab 10.0 includes Mattermost 4.2, an
open source Slack-alternative whose newest release includes interactive
message buttons to simplify complex workflows, plus much more.
This version includes security updates and an upgrade is recommended.
Cycle Analytics measures the time it takes to go from an idea to production
for each project you have. This is achieved not only by indicating the
total time it takes to reach that point, but the total time is broken down
into the multiple stages an idea has to pass through to be shipped.
With thanks to our community contributor, Mehdi Lahmam
it is now possible to view your cycle over a seven-day period which is great
for teams with very short release cycles.
When running pipelines, we have a lot of environment variables that are automatically set by GitLab,
giving your scripts the ability to access important information. Starting with GitLab 10.0, two new
variables, GITLAB_USER_NAME and GITLAB_USER_LOGIN, are now available to access the full name and
the login username associated to the account that is running the job.
In GitLab 9.2 we introduced Pipeline Schedules,
and in the following release we added
API and
variables support.
In GitLab 10.0, we complete the cycle adding variables support also to API calls.
Now automatic interaction with Pipeline Schedules by third-party applications can benefit of more flexibility.
GitLab provides the ability to share projects between different groups, giving
you even more flexibility with project structure and permissions.
Share locking
provides the ability to restrict projects in particular groups from being shared, to enforce
centralized security and policy.
Share locking has now been extended to subgroups, allowing subgroups to either
inherit or override share locking from the parent group, giving more granular
control over how projects can be distributed.
Previously, managing Service Desk issues required searching for issues authored by
the Support Bot on a project’s issue page. We now have a dedicated page accessible in the
navigation that does that for you automatically. We also display the support email
address itself on the page, allowing you to share it easily with anyone who you want
to send in support requests with Service Desk.
We have updated the group merge requests list page with the latest
search and filter bar UI. This allows you to narrow down the
merge requests you care about quickly, by author, assignee, milestone, label,
or weight, similarly to what you’ve been able to do for a few releases now
on the issue side.
The move issue functionality is now in the issue sidebar. This groups other
useful actions outside the main issue area, which is now focused on the title
and description only.
If you are using milestones and labels for your merge requests, you may
often be copying these objects from the issue to an associated merge request.
Now when you create a merge request from within an issue using the dedicated
button, the milestone and labels are automatically inherited into the merge
request.
For some users, resolving a merge request diff discussion means simply pushing new code to replace
the code in question. We’ve introduced a merge request setting to achieve exactly that. If the
setting is on, any diff discussions will be resolved if a push makes that diff section outdated.
Note that discussions on lines that don’t change and top-level resolvable discussions are not
automatically resolved.
LDAP Group Sync is available in GitLab Enterprise Edition and provides a
great hassle-free way to manage user permissions by leveraging your existing
LDAP group system and permissions.
GitLab further supports external users
allowing more restrictive control on projects on a case-by-case basis.
In GitLab 10.0 synchronizing external user permissions will happen at login, in addition
to the existing periodic synchronization. This means that any changes to permissions
in your LDAP system can be immediately available to the user after logging in and denying
access to unauthorized projects.
With thanks (again!) to our community contributor Mehdi Lahmam
it is now possible to filter the project view to show archived projects only.
This may be useful when managing projects to see a distinct list of all archived projects
and allow for easy deletion of archived projects by administrators.
As part of our ongoing effort to
translate GitLab into new languages, the Project Activity Page has now been made ready for translating.
We have recently created a Translation Community on CrowdIn making
it easy for anyone to help translate pages on GitLab. If you wanted to get involved, please
feel free to sign up through the community.
GitLab Geo has fully removed the use of system hooks. If you upgrade to GitLab 10.0, you MUST
enable SSH key lookups via the database.
We highly recommend Geo installations either upgrade to CentOS 7.4 or use Ubuntu 16.04 to get the required OpenSSH version.
We added improvements to the admin page for monitoring the database replication lag and log cursor state under an “Advanced” toggle (see screenshot below).
With every release we aim to make GitLab faster, more available, and more stable.
We’re committed not only to making
individual instances of GitLab even faster, but also to greatly improving
the performance of GitLab.com, an instance that hosts 1 million users!
In GitLab 10.0 we have doubled down on this commitment and addressed more
performance issues than any other previous release.
We are addressing high memory usage issues, making numerous pages a lot
faster as well as improving the speed of creating projects and performing commits.
With the release of GitLab 10.0 on September 22nd, support for Postgres 9.2
will end and it will be removed from the Omnibus GitLab package.
For deployments using packaged Postgres, upgrading to GitLab 10.0 requires
the database to already be running version 9.6.
If you are upgrading from at least GitLab 9.0, your database is already running
version 9.6. If you are running a version older than 9.0, please
upgrade your database
to prepare for GitLab 10.
PostgreSQL 9.2 is end of life in September,
five years after it was first released.
In GitLab 8.17 we announced the deprecation of API v3.
We are still seeing a high volume of traffic on GitLab.com using API v3
requests.
API v3 will be removed in GitLab 11 and we just wanted to ensure that developers
were migrating to API v4. Please refer to our documentation that shows changes
between the two API versions.
The GitLab Koding integration is being removed as we continue to enhance
GitLab’s in-line editing capabilities.
From GitLab 10.0 it will no longer be possible to activate Koding integration.
Existing installations that are currently using Koding may continue to do so
until GitLab 11.0 when this functionality will be completely removed.
GitLab 10 will no longer accept TLSv1 by default. If you would like to
continue to accept TLSv1 connections, it can be added back to the list of
supported protocols by editing the nginx['ssl_protocols'] field in gitlab.rb.
GitLab Git HTTP Server Configuration Support Removed
Since GitLab 8.2, we have used gitlab-workhorse
to process Git HTTP traffic. Earlier versions of GitLab used
gitlab-git-http-server, and configuration
entries for it have been ignored. With GitLab 10, we will be removing the code to recognize the
long-deprecated configuration parameters for gitlab-git-http-server. In the event your gitlab.rb
configuration file contains these entries, they should be removed or GitLab configuration will fail.
LDAP Config “verify_certificates” Defaults to Secure
The LDAP config option verify_certificates now defaults to true for security.
This option was added in 9.4.2 but defaulted to false for backwards-compatibility.
Installations that are using start_tls or simple_tls for the encryption
parameter and that unknowingly do not have SSL configured properly between the
LDAP server and the GitLab server, may break if the LDAP server’s SSL
certificate cannot be verified by the GitLab server.
Currently, the Git user on a GitLab server can have custom SSH client configuration
placed into ~git/.ssh/config.id_rsa and other configuration files are also picked up automatically.
This custom manual configuration is automatically picked up and used in a number of places.
However, it’s insecure as there are no per-gitlab-user access controls on use of the key.
With the release of GitLab 9.0, we changed how to
configure an alternate Git storage directory
in order to support multiple directories. Backwards compatibility was maintained for the
older formats to ease the upgrade process. In a future release of GitLab, we will no longer support the
older configuration parameter, and users should modify their gitlab.rb to support the
current git_data_dirs format.
For example if your gitlab.rb contains git_data_dirs({ "default" => "/var/opt/gitlab/git-data" })
it should be changed to git_data_dirs({ "default" => { "path" => "/var/opt/gitlab/git-data" } }).
Auto Deploy is now part of Auto DevOps, and no longer needs to have standalone templates.
With the incorporation in Auto DevOps, it has been improved with Helm Charts support
and persistent database instances, to make deployments even more usable for production.
Triggers with the legacy label do not have an associated user and only have
access to the current project. You are advised to take ownership of any legacy triggers.
In the first iteration of GitLab Code Quality, we hardcoded detection of the job by codeclimate.
We now officially look for codequality jobs, even if the old codeclimate is still working.
We’re also deprecating all service-management-related commands
(stop, start, restart, status, install, uninstall). They will be removed in one of the upcoming releases.
You can read more about the decision in the issue.
To upgrade to GitLab 10.0 from the latest 9.5 version, no downtime is required.
To upgrade without downtime, please consult the
documentation on downtimeless upgrades.
If you are upgrading from a version prior to 9.5, migrations will take a
significant amount of time based on the size of your database. For example on GitLab.com,
the set of migrations would take over 24 hours. For larger deployments, we recommend
upgrading to 9.5 first and allowing background migrations to run. Once completed,
then continue and upgrade to GitLab 10.0.
You can check the status of background migrations by running this command from the Rails console:
Sidekiq::Queue.new('background_migration').size
For this release we have migrations and post-deploy migrations.
GitLab.com migrations took approximately five minutes and post-deploy
migrations amounted for a total of around 15 minutes.
GitLab Geo users, please consult the documentation on upgrading Geo.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback