In this month’s release of GitLab 10.3 we’ve added new ways to ensure that your
code changes are both secure and fast, enhanced your planning and collaboration
workflow, and improved your ability to build and ship.
Security and testing
Not too long ago, we announced our ambitious vision for Complete
DevOps and with
GitLab 10.3 we're adding several exciting new features that help bring that
vision to life. Static Application Security
Testing and Browser Performance
Testing expand the scope of your CI/CD pipeline
with security and performance checks, respectively. SAST
has already been added as a best practice to Auto DevOps, with Browser
Performance Testing soon to follow.
Discussion and collaboration
In 10.3, we also include Merge Request Commit Discussions to allow you to start a
conversation on specifics commits within a merge request.
Thanks to our MVP, you can now
customize the branch name when you start a merge request from an issue. This
improvement is important to allow you to rapidly start MRs directly from
issues without having to break your branching strategy.
Sometimes an image is worth a million words. With GitLab 10.3, we added
support for flow charts, sequence diagrams, and Gantt diagrams in GitLab Flavored Markdown (GFM) with Mermaid.
Build and ship
GitLab 10.3 adds support for multiple Kubernetes clusters per
project, which enables a common
best practice of keeping your production cluster isolated from your dev and test
cluster(s).
With 10.3 we're shipping an enhancement to Auto DevOps. Now, when you enable
Auto DevOps for your project, the first pipeline will run automatically,
without needing to trigger it manually.
Artifacts can expire or be manually deleted so we're introducing strict checking on artifact dependencies, so that jobs
will fail if their dependencies cannot be found.
We're also shipping improvements to Merge Requests, Epics, Milestones,
Repository Mirroring, API, Geo, Runner, Protected Branches, Quick Actions, and
Issue Boards.
Read on to see everything that was released in GitLab 10.3!
We thank you for helping us to create great software with GitLab in 2017! We wish
you a Merry Christmas, happy holidays, and a new year full of great surprises!
Cheers!
Join us for an upcoming event
Key features released in GitLab 10.3
Static Application Security Testing (SAST)
Running secure application code in production is critical;
vulnerabilities can lead to everything from denial of service to leaked
user information. Running security checks on a regular basis helps
protect you from known vulnerabilities, even if they are affecting
libraries you import in your projects.
With GitLab 10.3, Static Application Security Testing (SAST) scans the
code (also known as static analysis) for known security issues that
could be exploited by malicious users, like unpatched external
dependencies or cross-site scripting vulnerabilities. It automatically
recognizes the most common languages (Ruby, JavaScript, and Python are
currently supported), and a summary shows up directly in Merge Requests
so your team is aware of potential problems before merging code into
master and deploying it to production. Static Application Security
Testing is also now part of Auto
DevOps to
provide security by default.
GitLab offers a great way to monitor the performance of your production
application, but it’s also critical to ensure that new code doesn’t
introduce performance regressions. For example, a developer may
incorporate a new image from design, but forget to compress it; or a new
JavaScript library may be added to <head>, slowing down page load.
Catching these regressions with only a manual review can be challenging.
To help address this, we are introducing an easy way to analyze the
performance impact of a merge request for web apps. Browser Performance
Testing runs a headless browser to simulate visiting one or more pages
of your application and analyzes them. A summary of performance changes
is provided on the merge request so you’re aware of the performance impact
before merging into master.
Merge Request Commit Discussions
GitLab works great for workflows where teams collaborate and comment on
each new version of a merge request.
But some teams work at the individual commit level; they want to have
conversations about every single commit, even within a push containing
multiple commits. This was not possible previously.
Today, we are shipping commit-based workflows in merge requests. Simply
navigate to the commits tab of a merge request and click on a commit to
bring you to the changes tab, with a new interface that allows you to
have a resolvable discussion about a particular commit. That discussion
is also shown in the discussion tab itself, along with other
conversations. This feature works alongside the existing workflow,
giving your team flexibility to select whichever flow works best. View a
short demo
of the new workflow.
Customize branch name when creating merge request from issue
You can create a merge request, along with an underlying branch, right
from an issue in one click. Clicking the create merge request button
automatically creates a branch name based on the title of your issue.
But in some cases you don’t really want this, especially if your issue
title is very wordy and you want the branch name to be more succinct. With
this release, you can now customize the branch name before creation.
This also works when creating a branch from an issue without an
associated merge request.
Thank you blackst0ne for the
contribution!
Flow charts, sequence diagrams, and Gantt diagrams in GitLab Flavored Markdown (GFM) with Mermaid
You can now create beautiful flow charts, sequence diagrams, and Gantt diagrams in issue / merge requests
descriptions and comments using GitLab Flavored Markdown (GFM)
Just follow the simple Mermaid syntax, now supported in GFM.
Thank you blackst0ne for the contribution!
Multiple Kubernetes clusters per project (Beta)
GitLab can easily deploy your application to different environments
within a Kubernetes cluster. We commonly see Development, Staging, and
Production, and Review Apps all published in the same way. Up until now,
they all lived in the same cluster, but you may have the need to keep
data and access separated, for example if regulations require you to
store production data in a different physical location.
With GitLab 10.3, you can configure multiple clusters for each project,
each linked to a specific environment, so the right cluster is
automatically used by CI/CD pipelines to publish your application.
Other improvements in GitLab 10.3
Automatically run first pipeline when enabling Auto DevOps
Previously in GitLab if you enabled Auto DevOps you still had to wait until
you pushed a commit before your pipelines would populate.
This was a confusing experience that didn’t follow expected behavior.
With GitLab 10.3, a pipeline for your project will be run as soon as you
enable Auto DevOps in Settings, so you can immediately see results without
needing to push another commit to your code.
Restricted deletion of CI/CD job logs
When running a job as part of a CI/CD pipeline, the job log is stored in
GitLab and is available for further analysis to users that have access
to the project. It can be also erased in order to avoid information
leaks or to free up space.
With GitLab 10.3, only Masters and the user that triggered the job are
authorized to erase the job logs; enforcing a more consistent permission
model.
Git push and pull on project redirects
Renaming and moving projects happens all the time. GitLab’s web user
interface has always redirected people from the old location to the new
location, but the same has not been true for Git actions.
From GitLab 10.3, Git actions will now redirect too! This means that any
build scripts, automation, or Git clients will continue to work after a
user or group rename, making any transition a lot smoother.
Please note, to avoid pulling from or pushing to an entirely incorrect
repository, the old path will be reserved.
Customize "New Project" page
With thanks to our community contributor, Markus
Koller, it is now possible for GitLab
administrators to add your own help text on the “New Project” page.
This is a great way to provide additional instruction to users on how
projects should be created. As this text supports Markdown, you can link
to any further pages or documentation to provide additional help.
Navigate to epic from issue
Since issues can only belong to one epic, when looking at an issue it’s useful to know if
it already belongs to an epic. The containing epic of an issue now appears in the issue
sidebar as a link, allowing you to quickly navigate to it.
Render links to epics in GitLab Flavored Markdown (GFM)
Links to epics in GitLab Flavored Markdown (GFM) textboxes will now be
rendered similar to issues, merge requests, and other objects in GitLab.
The group path is shown followed by &, and then the epic ID. A helpful
tooltip shows the epic title. This allows you to paste a link to an epic
in a textbox, and GitLab will render it more compactly and in a more readable fashion.
You can also directly enter the shorthand for the epic reference in the GFM field, such as
gitlab-org&23, and GitLab will turn that into link.
Sort milestones on group milestone list
You are now able to sort milestones on the group milestone list page,
similar to the project milestones list page. We introduced group
milestones a few releases ago and are working to bring features from
project milestones to group milestones.
Thank you George Andrinopoulos for the contribution!
Smarter autocomplete for label quick action
When using quick actions to add or remove labels to an issue or merge
request, the autocomplete dropdown is extremely helpful to quickly find
what you are looking for. With the latest change, autocomplete is even
smarter so that when adding a label, the dropdown doesn’t show labels
that are already added. And when removing a label, the dropdown only
shows labels that are already added.
Thank you blackst0ne for the
contribution!
Total issue time spent in milestone
Many teams track how much time is spent working individually on issues.
With this latest change, you can now see how much time is spent on all
of the issues in a single milestone, summed up together, in the sidebar
of the milestone page.
Thank you George Andrinopoulos for the
contribution!
Trigger pull mirroring via API
Pull mirroring, when enabled for a repository, automatically mirrors
changes from the configured upstream Git repository to your repository.
Changes are mirrored regularly when they are detected by polling.
A new API has been added to trigger changes to be pulled immediately.
When used with a push event webhook from the upstream repository, pull
mirroring can happen within seconds.
Restrict Repository Mirroring to admins
Push and pull mirroring, when enabled for a repository, will
automatically mirror to or from the configured target Git repository.
In GitLab 10.3 push mirroring can be restricted to admins. Now admins
can limit access to push and pull mirroring to only admin users, to
prevent repositories being replicated to or from a GitLab instance.
Simplified PostgreSQL HA configuration
In GitLab 10.2 Postgres HA became generally available, making it easy to set up a production Postgres database cluster using our Omnibus package.
Now we are making it even easier with the introduction of new Postgres roles. These roles significantly reduce the configuration required to set up standalone database nodes, by automatically turning off all other features and components.
GitLab Runner 10.3
We’re also releasing GitLab Runner 10.3 today! GitLab Runner is the open
source project that is used to run your CI/CD jobs and send the results
back to GitLab.
Most interesting changes:
List of all changes can be found in GitLab Runner’s CHANGELOG.
Handling oudated replicas with database load balancing
The database load balancer included in GitLab Enterprise Edition has
been improved so it can handle replicas that are lagging behind too
much. This has been combined with adjustments to the replica status
checks to reduce the number of queries necessary to check if a replica
is available.
These changes allow the database load balancer to stop sending read-only
queries to replicas when those replicas are lagging behind with
replicating data from a primary.
For more information check the merge request on
how we handled outdated replicas in the DB load balancer.
Strict check on artifacts dependencies
When dealing with CI/CD pipelines, it is quite common that artifacts are
created in one job and then used later by another job. Using the
dependencies keyword, you can explicitly list which artifacts from
previous stages you need. But when jobs are retried some time later,
those artifacts may no longer exist, for example if they have expired or
have been manually erased. This could lead to inconsistent states where
code is expecting to find resources that are not available, creating
errors that are hard to spot and debug.
In GitLab 10.3, we introduce strict checking on these dependencies. Since
jobs will fail if their dependencies cannot be found, you’ll always be aware
if something required is missing. This allows you to take proper actions
to solve the problem, for example running a brand new pipeline from scratch.
Improved integration with existing clusters (Beta)
Until now, configuring a project to use an existing Kubernetes cluster
(as opposed to creating a new cluster) relied on the service integration
page in the project settings. This made the flow inconsistent with the
first-class support for Clusters introduced in GitLab 10.1.
GitLab 10.3 adds the ability to add existing Kubernetes clusters to a
project, directly from the Clusters page, and deprecates the old service
integration page.
Show project member role on list of projects
When working with multiple projects, sometimes it’s difficult to remember what
permissions you have for each project. This can lead to frustrating situations and
not knowing why certain features aren’t available.
Having a quick reference that tells you what permission level you have helps you understand
your limitations and lets you act within them or request escalated privileges when appropriate.
Now you can see your permission level on the GitLab Project Dashboard next
to the project name. You no longer have to click into each project and
dig into the users page to find this info.
User and group additions to Protected Branch API
Protected
branches
allow you to lock down push or merge access to your repository’s
branches, preventing inadvertent changes entering your code or enforcing
particular workflows.
One great feature of protected branches is to specify users or groups
that do have permission to push or merge changes. This is now available
in the API.
Attach images to epics
You can now attach images (or any file) to an epic, via the epic
description, just like in an issue description (and other Markdown
boxes in GitLab). This allows you to be even more descriptive in
documenting epics, such as by including inline wireframes and mockups.
You are now able to update an issue’s weight right from an issue board’s
sidebar, exactly the same as in the issue page itself. This allows you to
quickly and more fully manage issues when doing planning and tracking
from within a board.
Redesigned merge request diff file navigation
The merge request diff file navigation has been redesigned to more
clearly show the file name in its own line. The file path is also now
truncated at the start if it is too long.
Create merge request through email
Some people prefer doing development as much as possible using their desktop
tools, reserving their use of the GitLab web interface for tasks which are
absolutely necessary there.
With today’s release, you can now create merge requests through email, expanding
the breadth of developer-focused features you can use with your existing tools.
Send an email to GitLab, specifying the source branch name in the email subject
line, and GitLab will automatically create the merge request for you. Find the
special (and unique-to-you) email address for a given project by clicking the link
at the bottom of the project merge requests page. It doesn’t change (unless you refresh it).
So you can safely save it in your email client.
For developers who do development, Git, and email all inside a terminal, you can now
do everything up to creating a merge request all without leaving that terminal.
Only mirror protected branches
Pull and push mirroring, when enabled for a repository, will
automatically mirror to and from the configured target Git repository.
But this fails if any pushes contain altered Git history, such as by
rebasing. It’s normally not a good idea to rebase certain key branches,
like master, but it’s more common for feature branches.
To prevent rewritten history from a feature branch causing mirroring to
fail, mirroring can now be limited to only protected branches.
Push mirroring, when enabled for a repository, will automatically
push changes to the configured downstream Git repository.
The rate limit has been updated to push changes immediately, but is
limited to one push every five minutes. If mirroring is limited to
protected branches, the rate limit is decreased to one push every
minute.
Improved Geo nodes dashboard
Managing and monitoring of Geo nodes is improved by separating the
monitoring interface from the process of adding and editing a Geo node.
Omnibus improvements
- Additional warnings have been added for deprecated settings, and they now appear in red.
- gpgme 2.1.15 is now packaged with Omnibus GitLab, making it easier to use signed commits.
- Git has been updated to 2.14.3
- Docker Registry has been updated to 2.6.2
- Redis has been updated to 3.2.11
We are continuing to make great strides in improving
the performance of GitLab in every release.
We’re committed to not only
making individual instances of GitLab even faster,
but also to greatly improving the performance of GitLab.com,
an instance that has over one million users!
In GitLab 10.3 we are shipping 24 performance improvements for merge
requests, CI/CD, Prometheus, frontend, and a lot more! Some of the
noteworthy improvements include:
Deprecations
GitLab Geo SSH repository sync
HTTPS repository sync replaces SSH repository sync for GitLab Geo. SSH
repository sync has been removed.
Refer to Geo node upgrade documentation
to enable HTTPS repository sync.
Deprecation date:
December 22nd, 2017.
Kubernetes integration service
The service integration for Kubernetes clusters
has been deprecated and replaced by the new Clusters configuration.
The integration is still accessible, but it will be partially limited in GitLab 10.4 and then eventually removed in GitLab 10.5.
Existing configuration will be automatically migrated to the new CI/CD > Clusters page in GitLab 10.5.
Deprecation date:
March 22nd, 2017.
The gitlab Helm chart
The gitlab Helm chart
is deprecated, and will be replaced by the new
cloud native GitLab chart.
A migration will be required to move from the current deprecated chart,
to the new cloud native GitLab chart.
Deprecation date:
March 22nd, 2017.
Mattermost configuration changes
With the release of GitLab 11.0, the number of Mattermost configuration options supported within
gitlab.rb will be reduced. We will continue to support the
core configuration settings
necessary to run Mattermost, and set up the integration with GitLab. Going forward, other
configuration settings should be set
directly within the Mattermost console, or passed as environment variables.
Presently with two applications attempting to write to the same config file, changes can be lost.
Deprecation date:
GitLab 11.0.
Upgrade barometer
To upgrade to GitLab 10.3 from the latest 10.2 version, no downtime is
required.
To upgrade without downtime, please consult the documentation on
downtimeless upgrades.
For this release we have migrations, post-deploy migrations, and background migrations.
You can check the status of background migrations by running this command
from the Rails console:
Sidekiq::Queue.new('background_migration').size
In this release we changed the directory structure layout that holds
artifacts. Artifacts are still stored in the same directory, but if you
sharded at a sub-directory level (which no one should be doing!), you should
review your infrastructure before upgrading.
Changelog
Please check out the changelog to see all the named changes:
Installing
If you are setting up a new GitLab installation please see the
download GitLab page.
Updating
Check out our
update page.
GitLab Subscription Plans
GitLab is available in
self-managed
and
cloud SaaS
options.
Self-managed: Deploy on-premises or on your favorite cloud platform.
- Core: For small teams, personal projects, or GitLab trials with unlimited time.
- Starter: For co-located teams with few projects who need professional support.
- Premium: For distributed teams who need advanced features, high availability, and 24/7 support.
- Ultimate: For enterprises that want to align strategy and execution with enhanced security and compliance.
Cloud SaaS - GitLab.com: hosted, managed, and administered by GitLab with free and paid subscriptions for individuals and teams.
- Free: Unlimited private repositories and unlimited collaborators on a project. Private projects get access to Free features, public projects get access to Gold features.
- Bronze: For teams that need access to more advanced workflow features.
- Silver: For teams that need more robust DevOps capabilities, compliance and faster support.
- Gold: Great with many CI/CD jobs. Every public project gets the features of Gold for free irrespective of their plan.
