Serverless computing dynamically allocates cloud resources whenever a piece of code is executed, optimizing allocation and distribution of the resources used to run your code. It is growing in popularity with developers because it allows them to focus on what matters most, namely writing code, without worrying about the underlying information technology infrastructure.
GitLab Serverless uses Knative, a Kubernetes-based platform, to build, deploy, and manage serverless workloads. This feature provides developers with an easy way to build and manage serverless workloads alongside the rest of their code, in a familiar user interface. For businesses, serverless enables a multi-cloud strategy and prevents being locked into a specific cloud provider.
With a built-in Container Registry and Kubernetes integration, GitLab makes it easier than ever to get started with containers and cloud native development. With 11.6, users will be able to create Kubernetes clusters for groups that can be used by all the projects contained within the group or sub-groups. This further simplifies cloud native configuration and allow developers to focus on developing great applications.
A few of our favorites include Suggested Changes, Web Terminal for Web IDE, and the Group Security Dashboard Vulnerability Chart. Team contributions are more easily accepted now that changes suggested (when leaving a comment on a merge request diff) can be accepted with a single click. Also, from the Web IDE, you can now launch a Web Terminal, the first server-side evaluation feature of the popular Web IDE. Building upon Group Security Dashboards released last month, the new Vulnerability Chart shows the security team how the number of vulnerabilities is changing day by day to provide resolution metrics.
Read on for all of the holiday goodies delivered with GitLab 11.6!
Key improvements released in GitLab 11.6
Serverless (alpha)
Building on the Knative integration introduced in GitLab 11.5, our new
Serverless capability allows users to easily define functions in
their repository and have them served and managed by Knative.
By simply defining your function data in the repo’s serverless.yml
file and using a .gitlab-ci.yml template, each function will be deployed to your cluster, with Knative
taking care of scaling your function based on request volume. This will
allow application developers to iterate quickly without
having to worry about provisioning or managing infrastructure.
Other improvements in GitLab 11.6
Authenticate with a smart card hardware token
For organizations operating in environments that use hardware tokens with
X.509 certificates and smart card capabilities for authentication (like
YubiKeys or Common Access Cards), GitLab now supports local user
creation and login.
Users can now use hardware tokens to access GitLab, increasing security and
avoiding the need for managing username/password credentials not
connected to a physical token.
Discord notifications
With this release, you can now integrate GitLab with
Discord, allowing you to send notifications
to a Discord channel in response to GitLab events, such as pushes to a
repository, updates to an issue, merge requests, and others.
Thank you Vitaliy Klachkov for the
contribution!
Improved issue and merge request dashboard filtering
We’ve updated the search filter bar design for the issues and merge
request dashboards, making it consistent with the similar search filter
bars in the rest of GitLab.
View open or closed epics on roadmap
We recently introduced the ability to close epics, as a way to indicate
that an epic is finished or no longer relevant.
With this release, we’re providing the option to view open epics,
closed epics, or both on the roadmap view. This is helpful for
teams that want to focus just on remaining and upcoming work (open
epics), that want to review finished work (closed epics), or see
recently finished work in conjunction with current work (both). This
feature provides that flexibility. Additionally, your selection is saved
to the system per user, so next time you return to a roadmap view, it
will be what you have selected previously.
SSH push mirroring support with public-key authentication
Repository mirroring allows you to replicate Git repositories from one
location to another. This makes it easier to work with multiple GitLab
instances by mirroring your repository in GitLab to a different server.
However, some target servers only allow Git access via SSH using
public-key authentication.
GitLab now supports SSH push mirroring with public-key authentication,
in addition to password-authenticated SSH and HTTP push mirroring.
Trigger variables are now hidden in UI by default
All trigger variables are now hidden by default in the UI and require a
manual action to display. This will prevent unintended exposure of
values when screen sharing or taking screenshots.
Improved project overview
With GitLab 11.6, we further iterate on the user interface of our
project overview page, by introducing a better balance for the project header,
improving whitespace and contrast to better highlight more frequently used
actions, and improving the overall information structure.
Breadcrumb navigation shows ‘New’ and ‘Edit’ for milestones and labels
With this release, we enhance our GitLab breadcrumb navigation structure
for milestones and labels. When creating or editing a milestone or label,
the breadcrumb context shows an additional ‘New’ or ‘Edit’ item, now
consistent with issues and merge requests.
Thank you George Tsiolis for the
contribution!
HTTPS support for JupyterHub
JupyterHub notebooks provide a powerful way for data teams to share
information. Oftentimes, sensitive data requires increased security.
Using Cert-manager for Kubernetes, JupyterHub will automatically
serve Jupyter over HTTPS, providing increased security for your
sensitive data.
Unlimited free guests for Gold plans
In 11.0, we introduced unlimited guest users for Ultimate plans.
We’re extending this to Gold plans, so groups using GitLab.com’s highest
plan, whether self-managed or cloud SaaS, can benefit from adding guests at no additional cost.
Markdown front matter filtering for TOML and JSON
Front matter is metadata included at the beginning of a markdown document,
often used by static site generators such as Jekyll
and Hugo. When GitLab displays
markdown files in repositories as rendered HTML, front matter retains its format and is displayed as-is, for clarity.
In addition to YAML front matter delimeters (---), GitLab now also supports TOML delimiters (+++), JSON
delimiters (;;;), and arbitrary delimiters, enabling the support of any data format.
Thank you Travis Miller for your
contribution!
Geo improvements
We continually focus on improving our Geo
feature for distributed teams. Some of the noteworthy improvements in
GitLab 11.6 include:
Omnibus improvements
- Postgres is now installed in a directory under its major version name, so updates within a major version no longer require a restart of the database.
- GitLab now supports connecting to Redis over SSL (rediss://).
- The
omnibus-gitlab container image’s sshd config now supports Git Protocol v2 by default.
- GitLab 11.6 includes Mattermost 5.5, an open source Slack-alternative whose newest release includes several bug fixes and performance improvements.
postgres has been updated to 9.6.11, ruby to 2.5.3, docker-distribution with a partial set of 2.7.0 commits.prometheus has been updated 2.5.0, prometheus-storage-migrator to 0.2.0, postgres-exporter to 0.4.7, and pgbouncer-exporter to 0.0.4.
Subscription details for Groups on GitLab.com
For paid plans
on GitLab.com, we want to make it easy to understand the status of your
subscription.
In 11.6, we have improved the Billing section underneath a group’s
Settings page to include details on your group’s plan. Now, you can
easily find your group’s current and past seat use, as well as the start
and end date of your subscription.
Promote issue to an epic
Software development is a creative process involving the whole team, and
ideas should be welcome from everyone. Ideas that emerge as issues can now
freely flow up into epics with the new issue promotion feature.
You can now promote an issue to an epic simply by using a new
quick action.
Just type /promote in a comment on the issue and hit Comment. This will
close the issue, and copy over the content of the issue into a new epic,
in the immediate parent group of the issue’s project. Labels,
participants, and even upvotes/downvotes will be copied over to the
newly created epic, in addition to the title, description, and comment
thread itself.
Per-user saved sort order in issues, merge requests, and epics
There are now user-specified sort order selections in issues, merge
requests, epics, and even roadmap views. Which type of attribute you
choose to sort by, and in which order you choose to sort (ascending or
descending), is saved to the system, so that when you return to the same
type of object list, it will remain what you have selected previously.
Similar issues
As projects grow and more issues are created, often the same issues are
created again and again.
To help people find answers faster, and save maintainers time, similar issues
are now shown when creating a new issue. In particular, they are shown when
entering the title in the new issue web form. This will help users see similar
issues right away, and allow them to navigate to them, and participate in
those existing conversations immediately, allowing for more collaboration
in GitLab.
Pipelines can now be deleted by project maintainers using API
Deleting a pipeline is now possible using the API, which allows for
cases where perhaps secrets have been leaked in a pipeline, many
unneeded pipelines have been created, or other issues have occurred
where pipelines need to be deleted.
Single email notification for Merge Request Reviews
Code review is an essential practice of every successful project, but
receiving email notifications for each comment can be overwhelming.
Reviews now only send a single email notification listing all the
feedback to help keep your inbox tidy.
Reviews,
added in GitLab 11.4, make code review easier, allowing comments to be
drafted, reviewed, and submitted in a single action.
This feature is available on GitLab.com today, and can be enabled
for self-managed GitLab instances using the batch_review_notification
feature flag. It will
be enabled by default for self-managed instances in GitLab 11.7.
User profile popovers
In this release, we introduce enriched popovers when hovering over a
username, starting with issue and merge request pages. While we previously
only displayed the full name, you can now view the user’s full
name, ID, company, and location information, as well as their status if
available.
Besides providing this extended tooltip on further pages, we are working
on follow-up enhancements for
issue and merge
request tooltips
that will be available shortly.
HTTPS Support for Auto DevOps
Auto DevOps aims to solve the many challenges posed when delivering
quality software. GitLab 11.6 furthers its capabilities by adding HTTPS
support.
Using Cert-manager for Kubernetes, Auto DevOps will automatically
serve applications over HTTPS, providing increased security for your
applications.
Show Kubernetes HTTP response code
To aid troubleshooting the installation of GitLab-managed apps in
your Kubernetes cluster, our integration will now return the HTTP
response code from Kubernetes, so resolving issues will be easier and
faster.
Disable impersonation of users by admins
For some organizations, allowing admin impersonation presents a security
risk since the actions of administrators are attributed to the user
they are impersonating. In order to address this, we’re adding a
configurable option to disable admin impersonations.
Auto DevOps support for Group Security Dashboard
In GitLab
11.5
we released the Group Security
Dashboard
where
SAST
results are displayed.
With 11.6, we update the Auto
DevOps template with the
latest version of the SAST
job definition, and
now results are fully compatible with the Group Security Dashboard, so
users can enjoy both features at the same time.
Note: The new SAST job definition requires GitLab
Runner 11.5 or above, you can read
more details in this blog
post.
GitLab Runner 11.6
We’re also releasing GitLab Runner 11.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:
A list of all changes can be found in GitLab Runner’s
CHANGELOG.
Performance improvements
We continue to improve the performance of GitLab with every release,
for GitLab instances of every size.
In GitLab 11.6 we have significantly reduced the memory usage of the
ReactiveCaching worker by switching to Nokogiri for XML parsing, and we’ve
halved the compressed payload size of the merge request discussions
endpoint.
These and other noteworthy performance improvements include:
The chart shows the reduction in memory usage by the ReactiveCaching
worker since deploying GitLab 11.6 to GitLab.com.
Deprecations
Ruby 2.5 required
Beginning with GitLab 11.6, Ruby 2.5 is required to run
GitLab. Omnibus GitLab already ships with Ruby 2.5.3,
but users of source installations that run Ruby 2.4 will have to upgrade.
Planned removal date:
Dec. 22, 2018.
GitLab Geo will enforce Hashed Storage in GitLab 12.0
GitLab Geo requires Hashed
Storage
to mitigate race conditions on Geo secondaries. This was noted in
gitlab-ce#40970.
In 11.5, we added this requirement to the Geo documentation:
gitlab-ee#8053.
With 11.6, sudo gitlab-rake gitlab:geo:check checks that Hashed
Storage is enabled and all projects are migrated:
gitlab-ee#8289. If
you are using Geo, please run this check and migrate as soon as possible.
In 11.7, we will add a dismissable warning that will be displayed on
the “Admin Area › Geo › Nodes” page.
In 12.0, Geo will enforce the Hashed Storage requirement:
gitlab-ee#8690.
Planned removal date:
Mar. 22, 2019.
Support for Prometheus 1.x in Omnibus GitLab
With GitLab 11.4 (Oct. 22, 2018) the bundled Prometheus 1.0 version is
deprecated in Omnibus GitLab. Prometheus 2.0 is now
included, however the metrics
format is incompatible with 1.0. Existing installations can upgrade to 2.0
and optionally migrate their data using an included
tool.
With GitLab 12.0 any installation not yet running Prometheus 2.0 will be
automatically upgraded. Metric data from Prometheus 1.0 will not be
migrated, and will be lost.
Planned removal date:
GitLab 12.0
TLS v1.1 will be disabled by default in 12.0
Beginning with GitLab 12.0, TLS v1.1 will be disabled by default
to improve security. This mitigates numerous issues including Heartbleed
and makes GitLab compliant out of the box with the PCI DSS 3.1 standard.
To disable TLS v1.1 immediately, set nginx['ssl_protocols'] = "TLSv1.2" in
gitlab.rb and run gitlab-ctl reconfigure.
Planned removal date:
GitLab 12.0
Removals and breaking changes
The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.
Upgrade barometer
To upgrade to GitLab 11.6 from the latest 11.5 version, no downtime is
required for multi-node/HA deployments. To upgrade without downtime,
please consult the documentation on downtimeless
upgrades.
Due to the ruby upgrade,
a single GitLab node will be down until the unicorn processes have been restarted. The
restart is done automatically at the end of gitlab-ctl reconfigure, which is run
by default on upgrade.
For this release we have migrations, post-deploy migrations, and to help
with the larger migrations, we have introduced background migrations.
GitLab.com migrations took approximately 25 minutes and post-deploy
migrations amounted for a total of around 2 minutes. Background migrations
on the other hand are sidekiq jobs that will run synchronously. For this
release these migrations took around 15 minutes to complete, and no side effects
were expected nor present.
GitLab Geo users, please consult the documentation on upgrading
Geo.
