GitLab 9.3 released with Code Quality and Multi-Project Pipeline Graphs
GitLab 9.3 Released with Code Quality, Multi-Project Pipeline Graphs, Conversational Development Index, Improved Internationalization, Snippet Descriptions, and much more!
GitLab is an integrated product for the entire software development lifecycle.
With each monthly release, we work to bring more aspects of social coding,
continuous integration, release automation, and monitoring into a single tool.
With GitLab 9.3, we're helping teams improve code quality, reduce cycle time and
make complex projects easier to manage.
GitLab 9.3 introduces Code Quality reports displayed directly in the Merge Request widget!
Code Quality gives you immediate insight into how a change will affect the health of your code and project.
This will reduce your review time and allow you to catch mistakes before merging a change.
Modern production-level software is often composed of many different projects,
especially those adopting micro-services architecture.
Therefore, understanding the relationships between these projects is crucial.
With GitLab 9.3, you can see how upstream and downstream project pipelines are linked together
with Multi-Project Pipelines Graphs.
In addition, this release gives you an extremely powerful way to compare your usage of
each facet of GitLab with other people, using the Conversational Development Index.
The ConvDev Index gives you a quick overview of how you perform in going from Idea to Production and
where you have the opportunity to optimise.
To give you a quick idea of the power of GitLab, we've recorded a short demo that highlights
some of GitLab's new features.
Enjoy the ability to have your entire development workflow in one single platform!
Huang was incredible in supporting our efforts to make internationalization
a first-class citizen of GitLab by leading the community efforts to source and
implement translations in new languages. Thank you Huang!
It’s hard to overstate the importance of proper code review. When reviewing changes, you will
need to pay attention to code quality, implementation, formatting, etc. Even with amazing reviewers,
consistency is impossible without the ability to measure quality.
To speed up code review and to give you the ability to check, measure and improve code quality,
we’ve built GitLab Code Quality. Code Quality will check your code and report changes in quality
directly in merge requests. This means your code reviews are faster and you guarantee that you’re not
accumulating technical debt. Of course, if the quality of your code goes down,
we will show you exactly where, so you can improve your code before merging.
Larger projects, especially those adopting microservices architecture,
often have a set of interdependent components that form the complete product.
It may be difficult for a developer to follow all the links between interconnected projects and understand why a specific pipeline has run,
or if another project has been rebuild because of a commit in the current one.
GitLab 9.3 is now able to display links for upstream and downstream projects directly on the pipeline graph,
so developers can check the overall status of the entire chain in one single view.
From now on, connections between different projects are clear and simple to follow, and they’re automatically created with no extra effort
when using $CI_JOB_TOKEN variable with triggers.
Last September we announcedConversational Development (ConvDev),
an evolution of software methodology that accelerates your development lifecycle,
from idea to production. By fully using GitLab’s integrated platform of features,
you can reduce that end-to-end cycle time.
With GitLab 9.3, we are shipping the ConvDev
Index to measure that feature usage. The ConvDev Index even compares your usage
with other top-performers using GitLab, helping you identify which parts of your
workflow you can further improve.
In this first iteration, the metrics are only available to GitLab
system administrators, aggregating data across your entire GitLab
instance amongst active users.
Secret variables are very useful if you want to avoid external people to
access private information for your project, but users that are able to modify the
project could still get access to it.
This might cause unintended people to affect production environments even if
they have no write permissions to the master branch.
In GitLab 9.3, Protected Variables introduce an additional layer of security
to your sensitive information, such as deploy credentials.
You can now mark a variable as “protected” when defining it in Settings -> CI/CD Pipelines, making it available only to jobs running on
protected branches, therefore only authorized users can get access to it.
Many companies have the need for audit and compliance across the
entire development cycle. In GitLab 9.3 any system administrator has
access to an improved, centralized Audit Log that includes all audit
events from Groups, Projects, and user actions.
The centralized Audit Log also includes the ability to filter events by
type and name, so you can easily track down events by group, project or user.
For JIRA users, we improved the JIRA integration settings in this release,
making it easier to set up and test your connection from your GitLab project
to a JIRA server instance. There is now also a separate Web URL field and
a JIRA API URL. This is useful for when your JIRA instance is configured
such that the JIRA REST API and the JIRA issues location do not share the
same URL.
The Reporter, Developer, Master, and Owner roles can now create and edit
group labels. Previously, only Master and Owner roles could do this. This
brings parity with permissions of project labels.
The issue description serves as the single source of truth when teams
collaborate on work and ideas are rapidly flowing in the issue comment
thread. With this release, you now edit the issue description by clicking
Edit, as before. But you remain on the same page, instead of going to a
separate web form. Just make your changes inline, and click Save changes
to persist the updates without refreshing the page. While editing, you can
also easily scroll down on the page to review comments and even copy GFM text
and paste it back into the description.
We recognize that teams use Issue Boards in a variety of ways. To make
it usable for even more teams, we now have collapsible Backlog and
Closed columns. We’ve also tweaked adding issues in a board.
When you click the plus sign +` to add an issue to a list,
it now appears at the top of the list automatically,
which is really helpful for long lists.
In GitLab 9.2
we started the process of
internationalization
with the Cycle Analytics page in German and Spanish. In GitLab 9.3 we
are extending this to more frequently used pages such as the Project
Home and Repository Files pages.
The GitLab community are already starting to add more languages such as
Chinese, Bulgarian, and Brazilian Portuguese. You can
follow the progress
and take a look at the
contributing guidelines
to get involved.
When you deploy your docker-based project, you need to pull your image
every time the deployment environment needs to start them. Since the
integrated GitLab Container Registry
is the natural choice to store your containers, in GitLab 9.3 you can
use it to distribute them too!
By creating a personal access token with the brand new read_registry
scope, you have a persistent deploy token that could be used by external
services, like Kubernetes, to access your images every time it’s needed,
without giving your full credentials or using a dummy user for this task.
During merge request code review, we are constantly making code changes
and commenting on those changes. It is often difficult to keep track. In
particular, suppose we start commenting on a particular code line, and there
are subsequent changes to that line. You may end up discussing something
that has already changed.
With this release, we added a system note to indicate that a line has already
changed, so that when you are participating in comments with respect to a
particular line, you know that it’s already been changed, and can even see
the change by clicking through.
In order to benefit from the
automatic cancellation of redundant pipelines
and save a lot of time during your development process, GitLab 9.3 sets this behavior to on for all existing and new projects.
If you really do want to disable it and keep redundant pipelines running, you can
tune the parameter to reflect your needs.
As part of the upcoming GitLab 9.4 release,
we will be upgrading the version of nginx included in our
Omnibus packages to the new stable release, 1.12.
Version 1.12 includes a number of improvements over the previous stable
release, including the ability to
filter the log output.
This will be a transparent upgrade for users, however if you have added
your own customizations
to the nginx configuration, please ensure they continue to work with version 1.12.
Snippets now have descriptions. This follows personal snippet comments, which
were added in the previous release.
Snippets are a great tool for quick and informal collaboration around code
ideas. We’re now bringing the power of issues and merge request collaboration
to snippets too.
We are continuing to make great strides improving the performance of
GitLab in every release. Not only will this make individual instances
of GitLab even faster, but will also greatly improve the performance
of GitLab.com, an instance that has over 1 million users!
In GitLab 9.3 we are continuing to make listing projects a lot faster
and improving performance overall server performance by making changes
to how we mirror repositories. Syntax highlighting on files will also
be cached to improve overall performance and make viewing commits
noticeably faster.
There are numerous other performance enhancements
in GitLab 9.3 that should not only make GitLab feel faster, but reduce
overall impact on server infrastructure.
We’ve made bulk editing issues even simpler and more intuitive in
this latest release. We’ve leveraged the sidebar paradigm that already
pervades GitLab. So users will feel right at home using a transient
sidebar when updating multiple issues at once.
In GitLab 9.0 we introduced Subgroups,
allowing for more flexibility and management of groups and projects.
We are continuing to improve this functionality in every release and in
GitLab 9.3 we are making the discoverability and navigation of
Subgroups a lot better. On the Groups page you can now see an
expandable tree view of all subgroups and projects rather than having
to navigate and explore them one page load at a time.
When viewing files in your repository, some extra information is now
automatically extracted and reported in the same page.
Starting with GitLab 9.3, you can see if your .gitlab-ci.yml or
.gitlab/route-map.yml are valid or not, and which are the parsing errors.
LICENSE files are also analyzed, and the information about the specific
license is easily accessible with a link for further details about it.
Dependency management systems are also exposed to make it clear what the projects rely on.
Ah, packages, those little gems (hah!) of wisdom wrapped up and ready for re-use.
GitLab will now automatically detect and link packages in the file view,
saving you valuable clicks every day. Neat, huh?
This functionality will work for the following packages and languages:
In GitLab 9.2 we
released Pipeline Schedules
that can be configured and managed using the UI.
Today with GitLab 9.3 we’re also releasing calls
to create and manage Pipeline Schedules through a set of APIs,
in order to allow integration with other tools simple and effective.
With
GitLab 9.2
we added the ability to see the memory impact of a merge,
by adding a sparkline to the Merge Request page. As part of GitLab 9.3 we are taking this
further and now quantify the change in average memory usage for the 30 minutes before and after the merge.
It is now easier than ever for developers to be cognizant of the impact they are
having on service performance, by getting direct feedback within the tool they already use every day.
GitLab 9.0 introduced Prometheus monitoring of the GitLab service, providing insight into Redis, PostgreSQL, and system performance.
As part of GitLab 9.3 we have added experimental monitoring of our ruby code base, starting with a handful of metrics like pipeline status and user sign ins. We will continue to instrument additional areas of GitLab in subsequent releases.
In 9.0 we released an enhancement to group management by
introducing subgroups.
Unfortunately, for performance and consistency, we have to drop this
feature on GitLab instances running MySQL. Subgroups will no longer be
available on MySQL in GitLab 9.3 and the upgrade process will migrate any
subgroups to the root of the GitLab server.
While investigating some occurrences of inconsistencies with project
membership, we discovered
that our approach to implementing subgroups was
not efficient enough. While PostgreSQL provides easy workarounds, MySQL
unfortunately did not provide any alternatives that did not require vastly
changing the way we store the hierarchy of groups.
In order to address the issue, we have removed support from
Subgroups in 9.3.
If you are running on MySQL and have created subgroups in your GitLab
instance, the upgrade process will convert any subgroups to regular groups.
We continue to support MySQL in general, although some features such as
GitLab Geo and
Zero-downtime migrations
are only available on PostgreSQL.
End of support for the openSUSE 42.1 Omnibus package
GitLab 9.3 will be the last version to include support for openSUSE 42.1,
as it is no longer supported by the community.
Starting with GitLab 9.4 (to be released on July 22nd, 2017) we will be offering
support for openSUSE version 42.2.
Changes to relative URL configuration in Omnibus installations now require a
sudo gitlab-ctl restart unicorn after reconfigure to take effect, in order to restart Unicorn.
Restarting Unicorn requires downtime.
To upgrade to GitLab 9.3, no downtime is required.
However we’re also migrating data for CI jobs and setting the auto-cancel redundant pipelines flag to on for all projects.
If you have a significant number of jobs or projects, this could take some time.
If you are using MySQL, you need to grant the database user used by GitLab the TRIGGER permission before upgrading, to prevent issues with migrations:
bash
mysql -u root -p -e "GRANT TRIGGER ON \`gitlabhq_production\`.* TO 'git'@'localhost';"
If you use MySQL with replication, or just have MySQL configured with binary logging,
you will need to also run the following on all of your MySQL servers:
bash
mysql -u root -p -e "SET GLOBAL log_bin_trust_function_creators = 1;"
You can make this setting permanent by adding it to your my.cnf:
log_bin_trust_function_creators=1
Starting with GitLab 9.1.0 it’s possible to upgrade to a newer version of GitLab
without having to take your GitLab instance offline. However, for this to work
there are the following requirements:
You can only upgrade 1 release at a time. For example, if 9.1.15 is the last
release of 9.1 then you can safely upgrade from that version to 9.2.0.
However, if you are running 9.1.14 you first need to upgrade to 9.1.15.
You are using PostgreSQL. If you are using MySQL you will still need downtime
when upgrading.
This applies to major, minor, and patch releases unless stated otherwise in a
release post.
A new version of our API was released in GitLab 9.0.
While existing calls to API v3 will continue to work until August 2017, we
advise you to make any necessary changes to applications that use the v3 API.
Read the documentation to learn
more.
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