GitLab 11.0 released with Auto DevOps and License Management
GitLab 11.0 released with Auto DevOps Generally Available, License Management, SAML SSO for Groups, open source Squash and Merge, and much more!
Writing and delivering quality software poses many challenges.
First, you must solve tough business problems and craft great code.
But the challenges don't stop there. You have to ensure your code
is fast, secure, and bug-free. You will need to build, integrate,
test, secure, review, configure, and deploy your code. Creating
and managing this pipeline is time consuming and complex.
Beyond making it easy to host and collaborate on public and private
repositories, GitLab also simplifies the rest of the process by
offering the whole delivery toolchain, built in. And now, it's not
only built in, it's automated. Simply commit your code and
Auto DevOps can do the rest. Auto DevOps is a pre-built, fully
featured CI/CD pipeline that automates the entire delivery process.
It is Generally Available and ready for prime time in GitLab 11.0.
Other key features we have released in GitLab 11.0 include
License Management to automatically detect licenses of
your project's dependencies; enhanced Security Testing
of your code, containers, and dependencies; further Kubernetes
integration features; an enhanced Web IDE; enhanced
Epic and Roadmap views; Incremental Rollouts; and much more.
“GitLab is a key part of our software-delivery processes and because
of them, we’ve improved our delivery velocity by four times and made
it immensely easier for our teams to collaborate,” said Chris Hill,
head of systems engineering for infotainment at Jaguar Land Rover.
“We’re excited about Auto DevOps, because it will allow us to focus
on writing code and business value. GitLab can then handle the rest;
automatically building, testing, deploying, and even monitoring our
application.”
License Management (software composition analysis):
Software is often a complex amalgamation of code that includes external components
(libraries, frameworks, and utilities). Each component typically includes
specific license permissions and limitations, so you need to track and manage
these dependencies for your application. GitLab 11.0 includes License Management
(software composition analysis) built into the Merge Request so you can track
and manage the included licenses.
Security: This month we continue to improve GitLab's built-in security
capabilities so you can "shift security left" and catch vulnerabilities early
via integrated Static and Dynamic Application Security Testing, along with
Dependency and Container Scanning. Specifically, we’ve extended coverage of
Static Analysis Security Testing (SAST) to
include Scala and .Net. We’re also including more
details in the SAST reports so you can get insight about specific issues
right there.
Kubernetes: As part of our ongoing effort to improve the integration
with Kubernetes and make it easy for you to manage and monitor Kubernetes
from GitLab, there are several new features. Most notably, when you need
to debug or check on a pod, you can review the
Kubernetes pod logs directly from GitLab's
deployment board.
GitLab Web IDE: The more work you can do directly from the IDE, the
more productive you can be. Now, you are able to
view your CI/CD pipelines from the IDE
and get immediate feedback if a pipeline fails. Switching tasks
can be disruptive, so the updated Web IDE makes it easy to quickly switch
to the next merge request, to create, improve, or review without leaving
the Web IDE. This way, you can stay in the flow of writing and reviewing
code changes.
Navigate Epics / Roadmaps: When you want to visualize how
Epics and Roadmaps flow over time, it can be helpful
to change the time scale and zoom out. We’ve updated the Epic/Roadmap navigation
interface to make it easier to see the big picture and make planning easier.
Vitaliy has contributed many times to GitLab, and has already been the release
MVP a couple of times this year.
For GitLab 11.0, he handled a large amount of technical debt by converting
most of our remaining Spinach tests to RSpec and relentlessly
working to fix GitLab for Rails 5. Also, once we decided to
bring the Squash and Merge feature into GitLab Core and GitLab.com free,
Vitaliy took on the issue and made it happen for this release.
Here are all the improvements he submitted to GitLab 11.0.
Vitaliy, you rock! Thanks again! 🙌 You’ll receive a brand new swag pack soon!
Originally introduced in beta in GitLab 10.0, Auto DevOps is now Generally Available (GA) in GitLab 11.0.
Auto DevOps provides a complete workflow for your project with minimal configuration, efficiently taking your
application from the build stage through the production and monitoring stage.
Auto DevOps brings DevOps best practices to your project by automatically configuring your build, test, Code
Quality, Static and Dynamic Security Testing, Dependency Scanning, License Management, Container Scanning, Review
Apps, Browser Performance Testing, deployment, and monitoring in a single application. It makes it easy for
teams adopting DevOps to start with a complete, holistic pipeline.
Auto DevOps enables developers to focus on what matters most to the organization – shipping code that brings
value to their customers.
Continuous integration is an important step in shipping high-quality
software, and you can now check the CI status of the current commit
at a glance by checking the status bar at the bottom left of the Web IDE. Even
better, you can view the status of each job and the logs for each job
on the right. This makes it easy to fix a merge request with CI
failures by opening the failed job side by side with the file you’re
working on.
Previously, fixing failed tests involved opening multiple tabs and
switching backwards and forwards. Now, all the information you need
can be opened right in the Web IDE, and
in the future
you’ll be able to preview and test your changes before you commit them.
It’s common to end up working on multiple merge requests across multiple
projects, and it now only takes one click to switch among your
assigned and authored merge requests. Whether you are reviewing others’ merge
requests, or trying to get your own over the line, the new
merge request switcher allows you to spend more time coding and
less time searching.
In modern software development, most applications rely on external components
to implement specific functions, preventing the need to code everything from scratch every
time. This is why third-party libraries are so common, and fetched directly by package
management tools like RubyGems or npm. However, this approach requires you to ensure
that the licenses for external components are compatible with your
application, and that there is no conflict that could lead to legal issues.
In GitLab 11.0, we are proud to introduce License Management as part of our
integrated development workflow. It automatically collects all the licenses
used by your dependencies and displays new ones in the Merge Request widget
before they land on your main default branch.
If you are using Auto DevOps,
License Management is
automatically enabled for your projects. Otherwise, you can
manually enable it
for your custom .gitlab-ci.yml definitions.
Being able to manage user credentials at scale is a must for large
organizations. Centralizing users on a company-controlled identity
provider is a common solution, and we have expanded our support for
authentication based on Security Assertion Markup Language (SAML) by
adding it to Groups.
Group owners are now able to configure an identity provider and
provide a single sign-on (SSO) link to users. By authorizing them
through the provided URL, groups can provide managed authentication
when instance-wide SAML is either unfeasible or not specific enough
for the group.
This is especially important for groups on GitLab.com, which can now
configure identity providers for enterprise use.
In the last major release, we unveiled GitLab’s new navigation.
With GitLab 11.0, we think it’s a good time to introduce an additional set of new navigation
themes! Five new user interface themes provide you with even more options to personalize your
GitLab experience.
Besides a fresh red theme, each theme received an additional light counterpart, allowing
you to make a bold color statement!
When working on a large feature, developers often push multiple commits to a work-in-progress
branch, and after code review, there may be even more commits to address various code
issues. Before merging that branch to master, many teams
prefer to squash all the commits into a single one, ensuring a clean Git history,
making it easier for folks in the future to review previous code changes.
Squashing is a Git feature and a developer can do it right before merging on their local
machine, but with squash and merge available directly in the GitLab web UI, you can
do it with just a single click. For example, a repo maintainer merging-in the code
can now do the squash without asking the code contributor to do so,
saving one extra round-trip communication step.
Squash and Merge, previously available in GitLab Starter, GitLab.com
Bronze, and higher tiers, is now open source and available in GitLab Core
and GitLab.com Free!
Many users have said that all teams would benefit from this feature, and we are happy
to bring it to everyone.
Since epics can take on any start and end dates, we wanted to provide a simple way for users
to quickly view the ones that are more relevant in a given time range.
With this release, we are introducing Roadmap date ranges. You can now quickly click Quarters, Months, or
Weeks, and immediately, the roadmap will be refreshed, enabling you see your epics from different
time perspectives. Teams who are focused on shipping features in the next few weeks can use one
granularity, while executive leadership folks who want a high-level overview can use the longer
time-period views.
Issue boards are a great tool for managing and tracking workflows, as your issues progress through different stages in
your lifecycle, with label lists representing those stages.
With this release, we are introducing assignee lists to issue boards. An assignee list shows issues that are assigned
to a specific user. This provides a whole new way to use issue boards: to view and manage issue assignments for your
team.
You can now configure a board
to a scope that matches that of your team, and then add assignee lists representing team members. This gives you instant
visibility into what issues your team is working on, whether you are a manager who wants an overview and status of the team’s
overall responsibilities, or an individual contributor who wants to sync up with another team member’s assigned issues.
You can even add label lists and assignee lists to the same board.
Subgroup support is also now consistent in the API when it comes to retrieving issues and
merge requests. That is,
if you query a particular group through the API for issues and merge requests, you will get results
from projects that are immediate children of that group, and also all from projects of all subgroups nesting down further.
This is analogous to viewing the same objects in the web UI’s group list views, which was introduced in recent prior releases.
While some applications may benefit from deploying every change into
production immediately after it’s done, others may fare better by grouping
those changes into a common environment for more thorough testing.
Configuring different deployment strategies for different projects
previously meant dealing with project-specific variables and then
exercising them as needed.
Starting in GitLab 11.0, Auto DevOps makes specifying your deployment
strategy a single-click event. When enabling Auto DevOps for a specific
project, you will be able to specify whether your application gets
automatically deployed to production or deployed automatically to
staging and then manually to production. This single-click configuration
will allow you to spend more time working on your apps and less time
configuring their deployment.
Merge request approvals are a longstanding GitLab feature that allows teams to enforce code review
(or any type of review) in a merge request, before unblocking it for merging.
Prior to this release, the feature had to be configured in the project settings. To simplify and
streamline the feature, approvals are now always on for all projects in GitLab (in Starter, Bronze, or higher tiers).
At the same time, however, we definitely do not want to slow down creating and merging code. So when a user
creates a project, the required number of approvals is by default zero for the project (essentially, the
feature is “off”). As the project grows, the user (and their team) can naturally adopt approvals by raising
that required number as appropriate to their workflow needs.
Creating Kubernetes clusters in GitLab has never been easier. With GitLab 11.0,
the “project” and “zones” values are automatically fetched from your Google
Kubernetes Engine (GKE) account and displayed as a list for easy selection.
Previously, creating a cluster using our GKE integration meant having to manually
enter this data.
Simple cluster creation will allow you to quickly stand up clusters from GitLab
and quickly deploy your apps.
Git LFS
helps to version large files with Git by storing them outside the
repository and lazily downloading files at checkout rather than clone.
When importing a project from GitHub, Bitbucket Cloud, or using a Git URL,
GitLab now imports LFS objects so that you have a complete copy of the
repository including those LFS objects. Previously, LFS objects were excluded
from imports.
As part of our effort to increase the availability of our security tools to the most common
languages and frameworks, we have been continuously iterating on Static Application Security Testing (SAST).
In GitLab 11.0, we add support for two new languages, .NET and Scala. Users don’t need to
change anything in their projects if they are already using Auto DevOps or the latest
version of the sast job definition in their .gitlab-ci.yml file.
JupyterHub is a multi-user
service for easily launching notebooks
across a data science team.
Jupyter notebooks provide a web-based interactive programming environment commonly
used for data analysis, simulation, visualization, and machine learning.
GitLab 11.0 can now deploy JupyterHub to an integrated Kubernetes cluster
with a single click, and it is automatically configured to use GitLab
for seamless authentication. Additional options like HTTPS,
group filtering, and custom notebooks
will be added in future releases.
GitLab allows for powerful asynchronous collaboration and communication. With the ability
to document ideas and have conversations in so many places, we encourage always maintaining
a single source of truth in the description area of an issue or epic.
This means that descriptions are often updated, many times in succession over a few minutes,
leading to multiple system notes that say that the description has been updated. With this release,
we are smartly combining those system notes if they happen within a short period of time,
cleaning up the visual clutter and making comments in GitLab just a little bit easier to navigate. We’ll
be adding the same functionality to merge requests in the next release.
We’ve decided to rename the Master role to the Maintainer role. It removes the negative connotations
that may be associated with the term “Master,” and at the same time, “Maintainer” is easily understood. Every
small step helps, and we hope to move forward at GitLab, and together as an industry.
We made a small change in the issues API scope attribute to bring it in line with our consistent
format of using snake case. The scope attribute now uses the values of created_by_me and assigned_to_me.
You should use this format starting in GitLab 11.0 instead of the previous kebab-case (hyphenated) equivalents.
In GitLab 10.6 we added the ability to see the IP address of a given GitLab Runner
in the details view in the UI. This is very useful to better recognize, troubleshoot,
and manage your infrastructure.
With GitLab 11.0, we also expose this information in the API response so that it can
be used by automated processes.
Starting from GitLab 11.0, the Omnibus GitLab package will check for deprecated configuration in gitlab.rb, prior to starting an upgrade. In the event deprecated configuration settings are found,
the package will abort the upgrade process prior to any changes. This allows the existing version to continue to run, while an administrator updates the problematic settings.
When running CI/CD jobs for your project, sometimes you need a way to differentiate one execution
from another. For this scope, you need a unique identifier that changes every time a new pipeline
is created. This feature was already available through the CI_PIPELINE_ID environment variable,
but this counter is unique for the entire GitLab instance and so it grows very fast, creating
possible problems with long numbers.
In GitLab 11.0 we are introducing another environment variable, CI_PIPELINE_IID, that contains
a reference that is specific to the project. It means that it is incremented only when another
run for the same project is created, keeping the value low and allowing developers to use it as
part of the release process, for example as part of the version number.
Projects that contain a .xcodeproj or .xcworkspace file can
now be cloned in Xcode using the new Open in Xcode button in GitLab.
When viewing Xcode projects in the GitLab interface, the button will be
available in GitLab next to the Git URL for cloning your project.
In order to help customers get the most from their GitLab instances, Guest
users no longer count against seat count for Ultimate licenses.
Since these users no longer consume seats (they’re effectively free to
add), it gives more users in an organization the chance to join the
instance and contribute to the conversation. You’re free to promote
these users, but they’ll count against your license’s seat count once
they’re promoted beyond Guest in any project or group.
This also means that if a user logs in and is never added to a project/group,
they have no role applied, therefore they are considered as ‘Guests.’
GitLab supports subgroups, and we have now leveraged that subgrouping structure for milestones. For any issue
or merge request, you can now assign it a project milestone or a group milestone inherited from any ancestor group.
In particular, you can now have a high-level group with a set of milestones at that level.
You can then use those same milestones in any issues and merge requests in any subgroups deeper down, providing a powerful
and flexible mechanism to organize work if you have nested groups and projects.
Furthermore, you can filter by this milestone in group issue lists and group issue boards, so that you can pull
in targeted objects from different levels in customized views.
Previously, when Auto DevOps was used for private or internal projects, the registry was
not accessible by Kubernetes after the deploy job completed. This prevented
the cluster from fetching the image again (for scaling, failures, etc).
With GitLab 11.0, a new deploy token is created to provide persistent access
to the registry when Auto DevOps is enabled on private/internal projects.
This will ensure that the cluster can perform necessary operations and
reduce possible failures.
Oftentimes we’d like to roll out changes to a subset of users or servers to
evaluate its impact before deploying across an entire environment. Previously,
Auto DevOps users had to make the Auto DevOps template explicit and then
define the desired behavior in order to achieve canary deployments.
Starting with GitLab 11.0, users are able to define their canary policy
by making use of the CANARY_ENABLED environment variable without the need to
customize the Auto DevOps template, enabling faster canary policy
declaration.
Developers often work on multiple merge requests at a time, and it can be a challenge to keep track of them
when many are open at once, awaiting collaborator reviews and feedback. Sometimes
a merge request becomes unmergeable because of a conflict, perhaps caused by a change on the target branch.
As a result, when you return to work on the merge request, you need to resolve the conflict.
With this release, GitLab can now send you a notification and even
assign you a todo if your
merge request becomes unmergeable. You’ll receive these as long as you are the author of the
merge request, or have set it to be merged once the pipeline succeeds. This allows you to be
proactive in fixing conflicts, or at least know what to expect when you revisit a merge request that
you had worked on previously.
Note: We originally missed mentioning this feature when this blog post was first published. This section has been added as of August 3, 2018.
When your application doesn’t precisely fit one or more Auto DevOps stages, such as unit testing, code quality, etc., it is ideal to customize the pipeline to run only the jobs you care about.
GitLab 11.0 now provides the ability to disable one or more Auto DevOps jobs through the use of environment variables. This allows you to take advantage of the power of Auto DevOps, even when your application doesn’t fit with one of its stages.
With the release of GitLab 11.0 we have added an Operations section in the navigation sidebar, making it quicker to access and easier to
discover our operations features. In this release Environments and Kubernetes have been moved from CI/CD to Operations, and we will continue
to add sections for features like Metrics and Logs in upcoming releases.
We are excited to announce that the cloud-native GitLab
Helm chart is now in beta. This chart features a more cloud-native architecture,
with a container for each component of GitLab and no requirement
for shared storage. These changes result in increased resilience,
scalability, and performance of GitLab on Kubernetes.
Issue weights in GitLab are useful for assigning effort estimation or any other cost metric
associated with working on an issue. Previously, you could only assign values 1 through 9
for an issue. But this meant that teams that wanted more granularity in their weighting were constrained.
Starting in this release, issue weights can take on any non-negative integer value, from 0 upward, giving you
unlimited flexibility in how you use weights. Furthermore, Burndown Charts
automatically consider these new weight values, so your team can immediately make use of an expanded range.
A fundamental need for all developers is to be able to review logs in order
to understand application behavior and troubleshoot any problems
that arise. With GitLab 11.0,
reviewing the logs of a troublesome pod is now just a click away.
On the Environments page, the status of pods for each application is
displayed using Deploy Boards.
Mousing over the pods will display the full pod name and status,
and clicking on the pod will then display the logs.
Labels are a powerful mechanism in GitLab. As teams continue to create and use more labels,
we want to ensure that managing them is easy. In this release, we’ve cleaned up the design
of the label list pages, simplifying the interface, making it easier to consume information at
a glance, and providing the UI affordances to quickly manage a particular label in further detail.
In GitLab 10.7, we added support for variables expressions to only and except keywords.
This allowed to define if a job should be created if a variable existed or had a specific value.
With GitLab 11.0, we are extending this syntax to allow regex. Now you can create more flexible
definitions based on a fine-grained pattern matching against the value. For example, you can skip
a job based on the commit message.
We’re also releasing GitLab Runner 11.0 today! GitLab Runner is the open source project
that is used to run your CI/CD jobs and send the results back to GitLab.
GitLab 11.0 includes Mattermost 4.10, an open source Slack-alternative whose newest release includes Environment Variables Support in GitLab Omnibus, faster load times, ability to convert channels to private, plus much more.
Added a new flag, master_on_initialization, to control if a database node should report it itself as master. This flag should be disabled on secondaries.
Prometheus rules can now be configured, providing the ability to add your own recording or alerting rules to the embedded Prometheus server.
The PgBouncer exporter has now been added, providing insight into its health and operation.
ruby has been updated to 2.4.4. git has been updated to 2.17.1. libpcre has been updated to 10.31. PgBouncer has been updated to 1.8.1.
Let’s Encrypt support has been added for the Registry and Mattermost. When new certificates are requested, these hostnames will be added to the certificate.
API v4 has been the preferred version of the GitLab API since 9.0. With GitLab 11.0, API v3 is removed and no longer supported.
See the differences between API v3 and v4.
With GitLab 10.0, we removed PostgreSQL 9.2 support, as it became end of life.
Going forward, GitLab requires PostgreSQL 9.5 or higher (MariaDB and MySQL support is available, but not recommended).
If you are using the Omnibus GitLab package, no action is required,
as it has automatically updated the bundled PostgreSQL to 9.6.
Due to published weakness in the ssh-dsa algorithm, we’ll wind down support for DSA SSH keys.
In 11.0, the default value for the DSA SSH keys setting is “Are forbidden”. This setting is located in the visibility and access controls section of the Settings admin panel.
This setting may be overridden if desired. Beginning in 12.0, GitLab will always reject DSA SSH keys.
With the release of GitLab 11.0, the number of supported Mattermost configuration
options in gitlab.rb has been reduced. We continue to
support the
core configuration settings
necessary to run Mattermost, and set up the integration with GitLab.
However other configuration settings now need to be set directly within
the Mattermost Console, or via environment variables.
Previously with both Omnibus GitLab and Mattermost Console writing to the same configuration
file, changes could be lost.
Legacy Git storage configuration no longer supported
With the release of GitLab 9.0, we changed how to
configure an alternate Git storage directory
in order to support multiple directories. Backwards compatibility was maintained for the
older formats to ease the upgrade process. With GitLab 11.0, we will no longer support the
older configuration parameter, and users need to modify their gitlab.rb to support the
current git_data_dirs format.
For example if your gitlab.rb contains git_data_dirs({ "default" => "/var/opt/gitlab/git-data" })
it should be changed to git_data_dirs({ "default" => { "path" => "/var/opt/gitlab/git-data" } }).
With GitLab Runner 11.0, we’ve changed the names of exported Prometheus metrics to make them more consistent with Prometheus community naming rules.
Old metric names will be unavailable starting with this release.
GitLab currently offers both project milestones and group milestones. In particular, you can assign issues within projects
of that group (and even within subgroups).
There is an existing feature in GitLab that allows you to pull in multiple project milestones with the same name, together
in one page. In the past, this was created to solve some of the use cases of how group milestones work now. But since we now have
group milestones as a first-class, native object, we no longer need this dynamically generated page. We will thus
deprecate these dynamically generated milestone pages.
On June 16, 2018, Mattermost 5.0 was released. In this version, Mattermost API v3 was removed, and only Mattermost API v4 is supported.
GitLab 10.8 or lower integrates with Mattermost API v3. So if you are using GitLab 10.8 or lower currently, and upgrade your external Mattermost
installation to 5.0, it will not work.
GitLab 11.0 integrates with Mattermost using Mattermost API v4. Mattermost API v4 is supported in Mattermost from 4.0 and up. So if you upgrade to
GitLab 11.0, your external Mattermost installation will still work, provided it is version 4.0 or up.
sast:container job and gl-sast-container-report.json artifact
Container Scanning was previously using sast:container for job name and gl-sast-container-report.json for the artifact name.
While these old names are still maintained they have been deprecated with GitLab 11.0 and may be removed in the next major release.
You are advised to update your current .gitlab-ci.yml configuration with the current convention.
Code Quality was previously using codeclimate for job name and codeclimate.json for the artifact name.
While these old names are still maintained they have been deprecated with GitLab 11.0 and may be removed in the next major release.
You are advised to update your current .gitlab-ci.yml configuration with the current convention.
GitLab Runner can be configured to host a Prometheus exporter, that provides metrics about its internals.
With GitLab Runner 11.0, the configuration setting that enables the exporter and defines listening address
was renamed from metrics_server to listen_address.
The old configuration option is deprecated and may be removed in the next major release.
In order to ensure successful upgrades to GitLab 11.0, the current version
must be 10.8 or above. The GitLab 10.8 package
includes additional checks for deprecated settings,
and will abort the upgrade in the event any are found.
Previously it was possible to upgrade with settings that are no
longer supported, causing the GitLab service to be unable to start.
For this release, the upgrade process includes migrations and post-deploy migrations.
When we upgraded our own GitLab.com instance, migrations took approximately 14 minutes and post-deploy migrations
amounted to a total of around 12 minutes.
GitLab Geo users, please consult the documentation on
upgrading Geo.
Raspberry Pi packages will be available starting with 11.0.2.
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