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.
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.
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!
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 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.
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.
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.
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!
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.
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.
Geo improvements
We continously improve our Geo feature for distributed teams. Some of the noteworthy improvements in GitLab 11.1 include:
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.
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.
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!
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.
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.
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!
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.
‘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.
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
size before deciding to download, for example.
Thank you Ahmet Demir for your contribution!
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!
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.
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.
Performance improvements
Some of the more noteworthy performance improvements in GitLab 11.1
include:
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback