Dec 22, 2017 - Mark Pundsack    
10.3

GitLab 10.3 released with Static Application Security Testing and Browser Performance Testing

GitLab 10.3 released with Static Application Security Testing, Browser Performance Testing, Multiple Kubernetes clusters per project, and much more!

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.

See all the features

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

GitLab MVP badge

This month's Most Valuable Person (MVP) is Vitaliy 'blackst0ne' Klachkov

Vitaliy is no stranger to the MVP list, having been the MVP of the GitLab 10.1 release. For 10.3, he added eight contributions, including one of the most requested issues, being able to customize the branch name when creating a new branch from an issue in the web UI. Another exciting one is Mermaid support in the Markdown viewer.

Thank you (again) Vitaliy for your contributions!

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.

Static Application Security Testing (SAST)

Read through the documentation on SAST


Browser Performance Testing

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.

Read through the documentation on Browser Performance Testing

Browser Performance Testing

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.

Read through the documentation on Merge Request Commit Discussions

Merge Request Commit Discussions

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!

Read through the documentation on creating a merge request from an issue

Customize branch name when creating merge request from issue

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!

Read through the documentation on Mermaid support in GFM

Flow charts, sequence diagrams, and Gantt diagrams in GitLab Flavored Markdown (GFM) with Mermaid

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.

Read through the documentation on Multiple Kubernetes clusters per project

Multiple Kubernetes clusters per project (Beta)

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.

Read through the documentation on enabling Auto DevOps

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.

Read through the documentation on the CI/CD permissions 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.

Learn how redirects work when the repository path changes

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.

Customize "New Project" page

Read through the documentation on customizing the "New project" page

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.

Navigate to epic from issue

Read through the documentation on Epics

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.

Render links to epics in GitLab Flavored Markdown (GFM)

Read through the documentation on GFM Special GitLab References

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!

Sort milestones on group milestone list

Read through the documentation on Group Milestones

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!

Smarter autocomplete for label quick action

Read through the documentation on Quick Actions

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!

Total issue time spent in milestone

Read through the documentation on the milestones sidebar

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.

Read through the documentation on triggering pull mirroring via API

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.

Read through the documentation on Repository Mirroring

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.

Read through documentation on PostgreSQL roles

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.

Read through the documentation on GitLab Runner

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.

Read through the documentation on database load balancing

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.

Read through the documentation on strict check on artifacts dependencies

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.

Read through the documentation on cluster integration

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 have to click into each project and dig into the users page to find this info.

Show project member role on list of projects

Read through the documentation on GitLab user roles and permissions

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.

Read through the documentation on Protected Branches 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.

Attach images to epics

Read through the documentation on Epics

Update issue weight from Issue Board sidebar

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.

Update issue weight from Issue Board sidebar

Read through the documentation on Issue Boards

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.

Redesigned merge request diff file navigation

Read through the documentation on merge request diff file navigation

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.

Create merge request through email

Read through the documentation on creating merge requests through email

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.

Read through the documentation on Repository Mirroring

Immediate push mirroring

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.

Read through the documentation on Repository Mirroring

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.

Improved Geo nodes dashboard

Read through the documentation on Geo node management

GitLab Mattermost 4.4.5

GitLab 10.3 includes Mattermost 4.4.5, an open source Slack alternative, whose newest release includes the beta release of plugin support, plus much more.

Read through the documentation on GitLab Mattermost

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

Read through the documentation on Omnibus GitLab

Performance improvements

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:

See all the performance improvements in GitLab 10.3

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.

Due: 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.

Due: 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.

Due: 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.

Due: 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 Products

GitLab is available in self-hosted and GitLab-hosted options.

Self-hosted

Deploy on-premises or your own private cloud.

  • GitLab Community Edition (CE): Open source, For small teams, personal projects, or GitLab trials with unlimited time.
  • GitLab Enterprise Edition (EE): Open core, fully-featured GitLab with with three licensing tiers.
    • Enterprise Edition Starter (EES): For co-located teams with a single project who need professional support.
    • Enterprise Edition Premium (EEP): For distributed teams who need advanced features, high availability, and 24/7 support.
    • Enterprise Edition Ultimate (EEU): For enterprises that want to align strategy and execution with enhanced security and compliance.

GitLab-hosted

GitLab.com is 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 repos get access to CE features, public open source repos 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 get the features of gold for free irrespective of their plan.

Cover image licensed under Unsplash free license

For the latest and most detailed news follow @gitlab on Twitter. Future blog posts suggestions RSS

Install GitLab in 2 minutes

With Ubuntu, Debian, CentOS, openSUSE, and Raspbian packages or from source

Install GitLab Now

Try GitLab Enterprise Edition risk-free for 30 days.

No credit card required. Have questions? Contact us.