GitLab 11.6 released with Serverless and Group-level Clusters
GitLab 11.6 released with Serverless and Group-level Kubernetes Clusters for even greater cloud native simplicity.
Deploy serverless workloads to any cloud via GitLab
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.
GitLab continues to simplify development of cloud native applications
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.
It's the holidays! Get excited! We've stuffed many more features into 11.6!
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!
Suzanne assisted GitLab in performing our recent
Voluntary Product Accessibility Template (VPAT)
review by organizing and verifying open accessibility issues, as well as
helping to assess the current state of the product through static analysis
tools and manual testing with assistive technologies. The VPAT evaluates
compliance with accessibility standards and is a great first step towards
improving accessibility so that everyone can contribute and use GitLab!
Thank you, Suzanne! We appreciate your contribution that enables more people to use GitLab.
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.
Running a given job only when dealing with a merge request is now easy.
Using the merge_requests value with only/except keywords will allow
you to configure jobs to run only (or except) when in the context of a
merge request. This allows finer control over pipeline behavior, and
also allows access to new environment variables indicating the target
branch and merge request ID when relevant, offering opportunities for
implementation of other more advanced behaviors.
Collaborating on merge requests is now easier – no more copy/pasting to
accept a suggested change. Changes can now be suggested when leaving a
comment on a merge request diff and accepted with a single click.
Changes can be suggested when commenting on a diff in a merge request,
and accepted by any user with write permissions to the source branch.
This feature is available on GitLab.com today, and can be enabled
for self-managed GitLab instances using the diff_suggestionsfeature
flag. It will be
enabled by default for self-managed instances in GitLab 11.7.
The Web IDE makes it faster and easier to contribute changes and resolve
merge request feedback by eliminating the need to stash changes and
switch branches locally. Yet, without a terminal to run tests,
experiment in a REPL, or compile your code, making large changes is
difficult.
From the Web IDE, you can now launch a Web Terminal so that you can work
in an editor side by side with a terminal, just like you would locally, to
inspect API responses or check your syntax in a REPL. The Web Terminal
is the first server-side evaluation feature of the Web IDE and is
configured using a new .gitlab/.gitlab-webide.yml file.
Interactive Web Terminals are not yet available on GitLab.com. You can
follow progress
here.
Changes are not currently synchronized between the editor and the web
terminal. In an upcoming release, we will add support for mirroring
changes and live
preview.
Project templates help you bootstrap new projects quickly. In
11.2,
we introduced project templates on the
instance level.
With GitLab 11.6, we are happy to announce this functionality is now
available for groups as well. By creating a sub-group within a new group
setting, projects in this sub-group become available as templates. This
streamlines the setup and ensures consistency across your projects,
especially in larger group structures, such as microservice architectures.
Often, development teams working on related projects
need to use the same Kubernetes cluster to deploy their
applications. Starting with GitLab 11.6, users are able to create a
group-level Kubernetes cluster that can be used for all projects
contained within the group or sub-groups.
This will greatly reduce the time/effort required to configure infrastructure
for your projects and allow you to focus on developing great
applications.
Securing applications is critical for production-grade deployments.
Cert-manager is a Kubernetes-native certificate management controller
that will automatically issue and renew SSL certificates using Let’s
Encrypt.
Using this SSL certificate will enable HTTPS for applications
served via Auto DevOps as well as for JupyterHub deployments.
The Group Security
Dashboard is
the primary tool where Security professionals can manage vulnerabilities
in their projects. One of the most important requirements is to know how the
number of vulnerabilities is changing day by day, and understand if the
team is solving problems quickly enough.
With GitLab 11.6, the Vulnerability Chart for Group Security
Dashboards enables you to easily view the graph of vulnerabilities from
the last month. For each severity level, you can read values for
vulnerabilities and move over the chart to see more details
about a specific point in time.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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_notificationfeature flag. It will
be enabled by default for self-managed instances in GitLab 11.7.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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