GitLab 11.1 released with Security Dashboards and enhanced code search

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

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.

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

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

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

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

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

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

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

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.

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

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 size before deciding to download, for example.

Thank you Ahmet Demir for your contribution!

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

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.