SAST security report on pipelines view
A few releases ago, we shipped Static Application Security Testing (SAST),
which automatically finds vulnerabilities in any new code changes in a merge request.
This allows you to fix them before merging, ensuring these security problems are not introduced
nto master and not released to production.
With this release, this same information is available in a complete SAST security report
in the CI/CD > Pipelines page. This allows developers, production/systems engineers, and
any other security stakeholders to have even more visibility into any security risks as your code
progresses through CI/CD.
External Authorization Control
In some regulated environments, project classification systems are used
to control access to projects, and can now be used with GitLab. When
enabled, admins can set the classification of each project. In addition
to GitLab access controls, access to projects will also require
approval from the external authorization service.
External CI/CD configuration in Starter and Bronze
In GitLab 10.5 we added the ability to include external CI/CD configuration files
into the main
.gitlab-ci.yml for your project. This feature was available only to Premium users on self-hosted Gitlab and Silver users on GitLab.com.
We received a lot of feedback from customers asking us to move this to a lower tier and we are excited
to bring this feature to even more users in this release by making it now available to Starter users on self-hosted Gitlab and Bronze users on GitLab.com.
The ability to have a centralized control over the pipeline configuration
and to reuse the same definition in multiple projects is something that is valuable for enterprises and smaller businesses as well.
Note that as part of our commitment to open source, public projects on Free GitLab.com
have features equivalent to a Gold level subscription. So those public projects will continue to have this feature.
Navigate to external issue tracker
Some teams use GitLab integrated with an external issue tracker. For example,
Jira issues integrated with GitLab merge requests is a popular workflow for many teams.
In this scenario, GitLab issues still function as normal, and teams are free
to use them, for example, in separate one-off scenarios where a team wants everything just in GitLab.
To streamline this integration, we’ve added a new link to the project navigation.
If you have configured any external issue tracker (Redmine, Jira, Bugzilla, or the Custom Issue Tracker),
there will be a separate link in the project navigation that allows you to quickly navigate to that
external system. The GitLab issues link remains so that there’s no confusion and also allows you to
use both issue trackers if you want.
Labels in Epics
GitLab issues and merge requests support labels to enable flexible and highly
customizable management of these objects. It’s an effective design that we’ve
also brought to Epics in this release.
You can now assign group labels to epics from the sidebar of an epic, exactly
the same as with issues and merge requests. And you can filter by labels on the epics
list page in a group, again like issues and merge requests. Users of GitLab
will thus find this feature immediately recognizable. This allows you easily
mix and match epics into different categories based on the powerful search and filter bar.
Along with the labels support mentioned above, we have maintained
parity with API support for Epics. You can get a list of epics based on the same search
and filter parameters of the search and filter bar in the web UI of the epics page. This includes
searching by the epic title and description, filtering by the author and labels, and ordering
by “created at” and “updated at” timestamps.
With this release, we have brought API support to discussions in issues,
snippets, and epics. This means that all comments and discussions (for issues)
are now accessible via the API. Teams can leverage this API for flexible,
customized, and specific workflows that are not necessarily in the main GitLab
API support for comments and discussions in merge requests will
also come in a future release.
Filipino, Indonesian, and Turkish language support
As part of our ongoing effort to internationalize GitLab, we have now
added support for Filipino, Indonesian and Turkish translations.
We have also externalised strings on the Repository Locked Files
(Premium and above) list page allowing our translation community to add
more languages and strings to GitLab.
If you are interested in contributing to GitLab’s internationalization
efforts, we welcome you to join our
GitLab Runner 10.6
We’re also releasing GitLab Runner 10.6 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.
Some of the more noteworthy performance improvements in GitLab 10.6
SAST for Java-Maven apps
Static Application Security Testing (SAST) feature.
In GitLab 10.6, we are adding Maven, a common build automation tool for Java.
If you are already using SAST, you don’t need to change anything in your configuration to get the new checks; they will
be automatically available.
See the complete list of supported languages and frameworks.
Authentication support for DAST
A few releases ago, we shipped Dynamic Application Security Testing (DAST),
allowing you to check for security vulnerabilities dynamically and automatically in a Review App
version of your work-in-progress code, before it is merged into master and released to production.
Previously, this feature was limited to public pages. With this release, you can now specify credentials that DAST
will use to authenticate into your web app and to simulate an attacker that is able to access sections protected
with a login process.
As projects and teams grow, so do the number of branches. The new
branches overview and filtered branches lists make it easy to quickly
find the branch you’re looking for. Branches with a commit added in
the last three months are shown as active.
Thank you Takuya Noguchi for the
Project import/export API
Projects are extremely important in GitLab, since they contain all the valuable
work (including the Git repo) and organization (including issues and merge requests) of your team.
Using the existing project export and import features of GitLab,
projects can easily be transferred within and between instances.
Up to now, this was a manual process. With this release, project
exports and imports are now part of the GitLab API, allowing you even
more automated and flexible workflows when you need move your projects
within or between GitLab instances.
Thank you Travis Miller for the
GitLab ChatOps (alpha)
For many organizations, much of their communication, including their
operations and troubleshooting discussions, is moving to chat. There
is also typically an “operations toolbox,” containing frequently used
commands to check on the health of an environment or to perform routine actions.
With GitLab 10.6 we wanted to make it easy to both automate these routine
actions, as well as bring them into Slack itself. Getting started is as
easy as adding a job to your GitLab CI YML, and enabling Slack
slash commands integration. Users will then be able to interact with it by typing
in the slash command, the CI job name, and then passing any relevant
arguments. The job will be executed on a runner, with the output being
sent right back to Slack.
Merge Request Approvals API
Prior to this release, the Merge Request Approvals API was limited to
approving and unapproving a merge request only. With this release,
you can now fully configure approvals at the project level and at the
merge request level, giving users feature parity with the GitLab web UI.
With the Approvals API, teams can now create more elaborate code review
and approval workflows that are specific to their needs. You can use as much
or as little of the API as needed to customize which parts of your workflow
happen inside the GitLab web UI, and which parts happen outside.
Business and other custom metrics
Since GitLab 9.0,
developers have been able to monitor critical system and response
metrics of their deployed apps, like throughput, latency, and
This provided a great baseline understanding of both the user
experience your customers were receiving as well as resource
utilization, directly in the tool they use every day.
With GitLab 10.6 we have added the ability to add your own metrics,
allowing deeper introspection of your application and business. For example
metrics from a credit card processing module can be added, tracking
not just success rates but also revenue and order size. This can help surface
failures that may not result in HTTP errors, as well as the ultimate impact
on business performance.
To get started, simply provide the Prometheus PromQL query and it
will begin to display in the dashboard.
Cloud native GitLab Helm chart (alpha)
We are excited to announce that the cloud native GitLab
Helm chart is now in alpha, and available
for testing. This chart features a more cloud native architecture,
with a container for each component of GitLab and no requirement
for shared storage. These changes result in increased resilience,
scalability, and performance of GitLab on Kubernetes.
It is important to note that the chart and containers are still
in active development, contain
known issues and limitations,
and should not be used for production. For this release
GitLab Premium is required, while we work to bring
Object Storage support to Core.
- GitLab Mattermost 4.7 includes enhanced image preview and thumbnails, faster load times, upgraded desktop app, and security updates. Upgrading is recommended.
- Chef has been updated to 13.6.4
- Omnibus has been updated to 5.6.10.
- PostgreSQL has been updated to 9.6.8.
- Python has been updated to 3.4.8.
- jemalloc has been updated to 5.0.1.
announce-port are now configurable for Redis/Sentinel, to better support HA in Docker environments.