GitLab 11.1 released with Security Dashboards and enhanced code search

Gitlab is an opensource software that can be installed into

Join us for an upcoming event

GitLab MVP badge




This month’s Most Valuable Person (MVP) is
Jasper Maes

This release’s MVP is Jasper Maes. Jasper has been and continous to be an integral
part of our ongoing effort to upgrade GitLab to Rails 5,
with awesome contributions over the last few months.

Thank you, Jasper, for your ongoing contributions to make GitLab better! We’ve sent Jasper
some GitLab swag as a thank you, including a hoodie, socks, and a handmade tanuki.




Key features released in GitLab 11.1




Security Dashboard for projects

Security professionals are focused on preventing threats that could harm the applications
they are responsible for. Even after code has been merged into the stable branch or deployed
to production, they need to be able to continually monitor and jump into any problems that
could affect security.

In order to make their life easier, GitLab 11.1 introduces the Security Dashboard that
reports the latest security status of the default branch for each project. This gives
a very accessible view to Security teams that can easily spot if something is wrong
and if actions must be taken. The new dashboard can be found in the Project
menu of the project’s side navigation. It is an interactive dashboard, so it can be used
to dismiss false positives or to create issues to solve existing vulnerabilities.

Security Dashboard for projects



See the documentation on Security Dashboard




File name and path filters for advanced code search

As teams generate large amounts of source code continuously, searching through all of that
code can be difficult. Having great tools to manage and, in particular, search through
all that source code is critical.

With this release, we are introducing new advanced search syntax options, allowing you to nail
down your code search via three more granular filters. You can now filter by filename,
file path, and even file extension when searching through repository code, resulting in
more targeted search results. These filters are available in both the Web UI and in the API.

For Core, these filters are available at the project-level scope.

For Starter and higher, if you use Elasticsearch
with GitLab, the filters are available at the group-level scope and global-level scope additionally.

For GitLab.com, the filters are available at the project-level scope only for all tiers, since Elasticsearch
is not yet available on GitLab.com. (We are, however, working on bringing Elasticsearch to GitLab.com.)



See the documentation on Advanced Syntax Search

File name and path filters for advanced code search




Container Scanning and DAST reports at pipeline level

Security reports in the merge request are very useful to spot new problems that are
introduced by new code, even before the code is merged into master. But since the
vulnerabilities can appear even before a merge request is created, sometimes developers
need to know the security status for a specific branch in a specific moment.

GitLab 11.1 completes the set of security reports shown in the pipeline view, adding both
Container Scanning and DAST. Simply review the Reports tab to access all
security information and take the proper actions.



See the documentation on security reports

Container Scanning and DAST reports at pipeline level




SAST support for Node.js

Static Application Security Testing allows you to spot code vulnerabilities
as soon as your changes are committed to the repository. With this information
available in the merge request, you can fix any detected vulnerabilities, so no
problems will land in production, adopting the ‘shift left’ approach automatically.

With GitLab 11.1, we add another great language to the list of supported SAST languages:
Node.js. You don’t need to change any setup in your Node.js project. The new language is
automatically detected and tested by the sast job.



See the documentation on SAST

SAST support for Node.js




Merge request widget info and pipeline sections redesign

In GitLab, merge requests and in particular, the merge request widget, is a powerful feature
showing you many integrated and relevant information and functionality. As such, we want to be
constantly evaluating the design and ensure that the information presented is as easy to consume
as it is useful.

In this release, we’ve tweaked the design of the information and pipeline sections, making
them easier to consume by breaking them slightly away from the rest of the widget content.



See the documentation on Merge Requests

Merge request widget info and pipeline sections redesign




Groups dropdown in navigation

Switching between groups should be an easy task that doesn’t disrupt
your workflow. To make this step easier than ever, we’ve added a
dropdown to the Groups link in the top navigation for quick access.

Searching for a group is now directly available behind a lightweight
dropdown menu, removing the need to navigate away from your work into
a separate view when you’re looking for a hard-to-remember group.
Similar to the Projects dropdown, your frequently visited groups
are also displayed.



See the documentation on Groups

Groups dropdown in navigation




View merge request description in the Web IDE

When working on a merge request or reviewing a merge request it can
help to refer back to the merge request description for why the changes
were made and further context.

With this release, instead of having to switch tabs, you can now open
the merge request description side by side with the code directly within
the Web IDE.



See the documentation on Web IDE

View merge request description in the Web IDE




Other improvements in GitLab 11.1




Contribution Analytics redesign

We redesigned the Contribution Analytics page for a more readable and
consistent user experience. We’ve focused on enabling this page to
handle a large number of contributors, so groups are now able to better
understand contribution patterns across many users.

Contribution Analytics redesign



See the documentation on Contribution Analytics




Milestone list pages redesign

In this iteration, we redesigned the milestone list, including the project list page,
the group list page, and the dashboard list page for a more consistent experience.

This is a first step in simplifying the design, making it more delightful and usable, ultimately
allowing teams to better manage their milestones.

Milestone list pages redesign



See the documentation on Milestones




GitLab subgroups in JIRA Development panel

Teams who use JIRA with GitLab have taken advantage of the JIRA Development panel integration.
This feature allows JIRA users to see GitLab merge requests, branches, and commits right
inside the right Development panel of a JIRA issue itself. In particular, you configure the integration
by pointing a JIRA instance to a GitLab top-level group. All projects in that group are now visible
to that JIRA instance.

With this release, we are extending that visibility so that all projects in that top-level group as well
as all subgroups nesting down are also known to JIRA. This gives even more power in your integration,
allowing you more flexibility to structure your projects in a hierarchy structure on the GitLab
side, without changing how you do issue management on the JIRA side.

GitLab subgroups in JIRA Development panel



See the documentation on GitLab’s JIRA Development panel integration




GitLab Flavored Markdown with CommonMark

GitLab Flavored Markdown (GFM) allows users to simply and quickly format and style text across GitLab, including
in issues, merge requests, epics, comments, and other places. Up until now, GitLab was using
Redcarpet, an older implementation of Markdown to support GFM. This resulted in
a number of issues.

With this release, GFM is now rendered using CommonMark, a modern
standard, for new Markdown content. (Existing Markdown content continues to be rendered with Redcarpet.
See the docs for additional details.)
Besides solving many of the aforementioned issues, CommonMark is more performant. Additionally,
GitHub has also standardized on CommonMark. So GitHub users coming to GitLab will now have the same
experience with Markdown. Additionally,
in the future when repository Markdown files will be rendered in CommonMark,
importing GitHub projects to GitLab will render Markdown files the same way.

Thank you blackst0ne for your contribution!

GitLab Flavored Markdown with CommonMark



See the documentation on GitLab Flavored Markdown




Confidential issue quick action

You can now set an issue to be confidential via a quick action right from the issue comment field.
This allows you to type a comment and set an issue to confidential, all without leaving the keyboard.

Thank you Jan Beckmann for your contribution!

Confidential issue quick action



See the documentation on Quick Actions




Autocomplete epics and labels in epics

In this release, we’ve improved autocompletion in epics. In particular, when you are typing
in a GitLab Flavored Markdown textbox in an epic (that is, the description or in a comment),
you can type the & character, and GitLab will autocomplete search for epics in that group. Similarly,
typing ~ will autocomplete search for labels, similar to issues and merge requests already.

Autocomplete epics and labels in epics



See the documentation on Epics




Merge request comments Vue.js refactor

Since 2016, when GitLab decided to adopt Vue.js, we’ve been
using it not only to build new features but also to refactor existing ones in order to allow for more interactive user interfaces
and increased performance.

In this release, the merge request comments user interface has been rewritten to allow for better control of performance in upcoming
months, as well as set the groundwork for creating new features more efficiently and cleanly using Vue.js. (For example, we are already
working on batch commenting).

See the ongoing improvements for this refactor beyond
what we have already merged for this release.

Merge request comments Vue.js refactor



See the documentation on Merge Requests




Issue board configuration API

We previously released a feature called Configurable issue boards
in GitLab 10.2, allowing teams to save a configuration issue scope, per issue board.
This feature is now available via the GitLab API.

This allows teams to create their own custom and/or even automated workflows.
For example, if you wanted to re-use the same issue board each iteration to
represent your team’s workflow, you can now change the configuration’s milestone
via the API, and have that be automated through an external script run in between
iterations.



See the documentation on Issue Board Configuration API




Merge request locked state in API

In this release, we added the locked state of a merge request to the GitLab API. This was
a previously internal-only state not exposed in the API. A merge request is in this locked
state while the source branch is being merged into the target branch.

By allowing access to this state in the API, external systems can no access all merge
requests reliably, even merge requests that are in this tranisent locked state.



See the documentation on Merge Requests API




Transfer projects between namespaces via API

In the project settings, Owners can transfer an existing project into another namespace.
This allows for flexible organization of projects within groups and personal userspaces.

With this release, we add access to this settings via our project API, allowing you to
bulk-move many repositories in one go.

Thank you Aram Visser for your contribution!



See the documentation on Transfering projects




Initialize README on project creation

At GitLab, we believe that everybody can contribute. Making the creation of a new GitLab
project as straight-forward and intuitive as possible is an essential step towards this
goal.

With GitLab 11.1, we introduce a new option to initialize a repository by adding a README
when creating a new project. If this option is checked, a project repository is initialized
with a default master branch which can be cloned right away.
The created README file includes the project name and description.

Initialize README on project creation



See the documentation on Project creation




Improved user experience on SSH key configuration

Using GitLab, anyone should be able to contribute and push to projects without a daunting
learning curve. With this ideal, we found
that configuring SSH, a core requirement to start contributing, remains a hard thing to do.

With this release, we improve the user experience of and documentation for our SSH Keys user setting.

Improved user experience on SSH key configuration



See the documentation on GitLab SSH keys




Improved Web IDE staging and committing

In this release we’ve made it easier to commit your changes in the Web
IDE with a pre-filled commit message and the ability to Stage &
Commit
your changes with one click. When editing a branch you don’t
have write permissions to, like the master branch, the Web IDE will
default to the Create new branch option, including a prefilled branch
name so you can always commit your changes with a single click.

Previously, the commit message was not pre-filled and the commit button
would be disabled when opening the Commit panel. This made it hard to
commit changes quickly and it was unclear why the Commit button was
disabled.

Improved Web IDE staging and committing



See the documentation on Web IDE




‘Contribute to GitLab’ link

GitLab is only as strong as its community, and nothing energizes us more
than empowering new contributors!

With this release, we make it easier for GitLab Core and GitLab.com users
to find our GitLab contribution page with a handy link, available right
away from your user profile menu.

'Contribute to GitLab' link



See our handbook on Contributing to GitLab




Allow SAML assurance level to bypass 2FA

In many cases SAML providers already support or even enforce two-factor
authentification natively via an assurance level property.

With GitLab 11.1, it is now possible to honor the SAML assurance level
allowing to disable the two-factor authentification on GitLab side via a
new SAML configuration option.

Thank you Roger Rüttimann for your contribution!



See the documentation on SAML OmniAuth Provider




New HEAD method in File API

Our repository files API allows CRUD (create, read, update and delete) operations on
files stored within your GitLab projects.

With GitLab 11.1, we add support for the HEAD HTTP method to our files API that
allows to just read file metadata. This request could be used to check for a file
siize before deciding to download, for example.

Thank you Ahmet Demir for your contribution!



See the documentation on Repository files API




Improved Kubernetes Cluster page design

We have improved the Kubernetes page design to make use of tabs for each
option when adding a cluster, minimizing the amount of irrelevant options
shown on-screen.

This is the first step in a series of changes that will enhance the design
of cluster addition and management, making it easier and more intuitive.

Improved Kubernetes Cluster page design



See the documentation on Kubernetes Clusters




Application Metrics now available in Operations menu

Viewing your application’s performance metrics is now easier and quicker than before,
with the addition of Metrics to the Operations menu. Clicking on Metrics will directly
open the performance dashboard for your production environment, if you have one, as well as provide
an easy drop down to change to other environments as desired.

Previously users had to navigate to the Environments menu, find the desired environment, and then select
Monitoring button. Switching to another environment required going back through this process. With GitLab 11.1,
your production metrics now are just one click away!

Application Metrics now available in Operations menu



See the documentation on monitoring applications




Manage third party offers

With GitLab 10.8 we began to inform users of third party offers they might
find valuable in order to advance the development of their projects.

There may be instances were these offers are not applicable or you simply don’t
want them shown on the application. With GitLab 11.1 we introduce the ability
to control the display of third party offers in the administration area, providing
more control over the display of these offers.

Manage third party offers



See the documentation on Third party offers




Store user ID in OpenID Connect sub claim

GitLab can be used as an OpenID Connect (OIDC) identity provider to sign into
external services. This layer is built on top of OAuth 2.0.

In previous version, we were storing the sub claim of OIDC based on a hashed
version of the GitLab user ID. This could lead to a potentially unstable API as
the obfuscation is tied to GitLab specific logic.
With GitLab 11.1, we are directly storing the user ID in sub, following the
OIDC specification. To allow migration, the previous value is still available in
the sub_legacy claim.



See the documentation on OpenID Connect




GitLab Runner 11.1

We’re also releasing GitLab Runner 11.1 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 in this release include:

List of all changes can be found in GitLab Runner’s CHANGELOG.



See the documentation on GitLab Runner




Omnibus improvements

  • GitLab 11.1 ships with Mattermost 5.0,
    an open source Slack-alternative whose newest release includes a post
    interception feature, increased character limit on posts, combined join/leave messages, plus much more.
  • Raspberry Pi packages are now available for Raspbian Stretch.
  • Omnibus has been updated to 5.6.12.
  • Prometheus can now be configured to read and write to remote services.
  • Prometheus exporters have been updated, and some metric names have changed: node_exporter 0.16.0, alertmanager 0.15.0, postgres_exporter 0.4.6, redis_exporter 0.20.2.



See the documentation on Omnibus GitLab




Milestone list pages redesign

In this iteration, we redesigned the milestone list, including the project list page,
the group list page, and the dashboard list page for a more consistent experience.

This is a first step in simplifying the design, making it more delightful and usable, ultimately
allowing teams to better manage their milestones.

Milestone list pages redesign



See the documentation on Milestones




GitLab Flavored Markdown with CommonMark

GitLab Flavored Markdown (GFM) allows users to simply and quickly format and style text across GitLab, including
in issues, merge requests, epics, comments, and other places. Up until now, GitLab was using
Redcarpet, an older implementation of Markdown to support GFM. This resulted in
a number of issues.

With this release, GFM is now rendered using CommonMark, a modern
standard, for new Markdown content. (Existing Markdown content continues to be rendered with Redcarpet.
See the docs for additional details.)
Besides solving many of the aforementioned issues, CommonMark is more performant. Additionally,
GitHub has also standardized on CommonMark. So GitHub users coming to GitLab will now have the same
experience with Markdown. Additionally,
in the future when repository Markdown files will be rendered in CommonMark,
importing GitHub projects to GitLab will render Markdown files the same way.

Thank you blackst0ne for your contribution!

GitLab Flavored Markdown with CommonMark



See the documentation on GitLab Flavored Markdown




Autocomplete epics and labels in epics

In this release, we’ve improved autocompletion in epics. In particular, when you are typing
in a GitLab Flavored Markdown textbox in an epic (that is, the description or in a comment),
you can type the & character, and GitLab will autocomplete search for epics in that group. Similarly,
typing ~ will autocomplete search for labels, similar to issues and merge requests already.

Autocomplete epics and labels in epics



See the documentation on Epics




Issue board configuration API

We previously released a feature called Configurable issue boards
in GitLab 10.2, allowing teams to save a configuration issue scope, per issue board.
This feature is now available via the GitLab API.

This allows teams to create their own custom and/or even automated workflows.
For example, if you wanted to re-use the same issue board each iteration to
represent your team’s workflow, you can now change the configuration’s milestone
via the API, and have that be automated through an external script run in between
iterations.



See the documentation on Issue Board Configuration API




Transfer projects between namespaces via API

In the project settings, Owners can transfer an existing project into another namespace.
This allows for flexible organization of projects within groups and personal userspaces.

With this release, we add access to this settings via our project API, allowing you to
bulk-move many repositories in one go.

Thank you Aram Visser for your contribution!



See the documentation on Transfering projects




Improved user experience on SSH key configuration

Using GitLab, anyone should be able to contribute and push to projects without a daunting
learning curve. With this ideal, we found
that configuring SSH, a core requirement to start contributing, remains a hard thing to do.

With this release, we improve the user experience of and documentation for our SSH Keys user setting.

Improved user experience on SSH key configuration



See the documentation on GitLab SSH keys




‘Contribute to GitLab’ link

GitLab is only as strong as its community, and nothing energizes us more
than empowering new contributors!

With this release, we make it easier for GitLab Core and GitLab.com users
to find our GitLab contribution page with a handy link, available right
away from your user profile menu.

'Contribute to GitLab' link



See our handbook on Contributing to GitLab




New HEAD method in File API

Our repository files API allows CRUD (create, read, update and delete) operations on
files stored within your GitLab projects.

With GitLab 11.1, we add support for the HEAD HTTP method to our files API that
allows to just read file metadata. This request could be used to check for a file
siize before deciding to download, for example.

Thank you Ahmet Demir for your contribution!



See the documentation on Repository files API




Application Metrics now available in Operations menu

Viewing your application’s performance metrics is now easier and quicker than before,
with the addition of Metrics to the Operations menu. Clicking on Metrics will directly
open the performance dashboard for your production environment, if you have one, as well as provide
an easy drop down to change to other environments as desired.

Previously users had to navigate to the Environments menu, find the desired environment, and then select
Monitoring button. Switching to another environment required going back through this process. With GitLab 11.1,
your production metrics now are just one click away!

Application Metrics now available in Operations menu



See the documentation on monitoring applications




Store user ID in OpenID Connect sub claim

GitLab can be used as an OpenID Connect (OIDC) identity provider to sign into
external services. This layer is built on top of OAuth 2.0.

In previous version, we were storing the sub claim of OIDC based on a hashed
version of the GitLab user ID. This could lead to a potentially unstable API as
the obfuscation is tied to GitLab specific logic.
With GitLab 11.1, we are directly storing the user ID in sub, following the
OIDC specification. To allow migration, the previous value is still available in
the sub_legacy claim.



See the documentation on OpenID Connect




GitLab Runner 11.1

We’re also releasing GitLab Runner 11.1 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 in this release include:

List of all changes can be found in GitLab Runner’s CHANGELOG.



See the documentation on GitLab Runner




Upgrade barometer

You can upgrade to GitLab 11.1 from 11.0 without any downtime. See the documentation on
downtimeless upgrades
.

For this release we have migrations, post-deploy migrations, and to help with a possible
larger migration we have introduced one background migration.

When we upgraded our own GitLab.com instance, migrations took approximately 30 seconds and
post-deploy migrations amounted to a total of around 1 minute.

GitLab Geo users, please consult the documentation on
upgrading Geo.

Gitlab is an opensource software that can be installed into
>
WhatsApp WhatsApp us