With our shipment today of GitLab 11.3, we are excited to announce
support for Maven repositories, Code Owners, Protected Environments, and epic forecasting. These features help
automate controls around environments and code while providing further efficiencies for
Java developers.
We have expanded our support for Java projects and developers by
building Maven repositories directly into GitLab.
This provides Java developers with a secure, standardized way to share
version control in Maven libraries and save time by reusing
these libraries across projects. This feature is available with GitLab Premium.
Code Owners and Protected Environments
GitLab Starter now supports the assignment of Code Owners to files
to indicate the appropriate team members responsible for the code. This feature prepares us for futures releases that will enforce
internal controls at the code level.
Available in GitLab Premium, operators can also use Protected Environments
to set permissions determining who can deploy code to production environments.
This significantly reduces the risk of the wrong person committing something they
shouldn’t and increases overall security of the environment.
A new Portfolio Management feature in GitLab Ultimate can automatically
forecast an epic's start and end dates
based on the milestone dates of its issues. With this enhancement,
portfolio managers will be able to compare their planned start and end dates against
the work that is scheduled through milestones, gaining visibility into potential
slippage in epic delivery. This will enable faster, better decisions on what can be
delivered and when plans need to be adjusted.
Many of these improvements were contributed by the greater GitLab community.
We look forward to your feedback and improvements on these great new features.
Together, we make an awesome team! 🏆
Let us know what you think in the comments below. What are you looking
forward to in this release? What can we continue to improve on?
Join us for an upcoming event
Watch the 11.3 Release Radar webcast
This month's Most Valuable Person (MVP) is
George Tsiolis
George added a very popular and highly requested feature that allows users to
include private contributions
on their own profile page.
Thank you, George, for your ongoing contributions to make GitLab even better!
You’ll receive a brand new swag pack soon!
Key features released in GitLab 11.3
Maven repository
For any development organization, having an easy and secure way to manage
dependencies is critical. Package management tools, such as Maven for Java developers, provide
a standardized way to share and version control these libraries across projects.
In GitLab 11.3, we are proud to offer Maven repositories built directly into GitLab. Developers of
lower-level services can now publish their packaged libraries to their project’s Maven repository.
They can then share a simple XML snippet with other teams looking to utilize that library,
and Maven and GitLab will do the rest.
Check out a sample project which builds and
pushes to the GitLab Maven repository, and see how easy it is!
Interactive web terminals for Shell and Kubernetes Runners
CI/CD jobs are executed by runners based on the configuration provided
by users in their pipeline definition. But this execution is not
interactive and, if it fails, users cannot dig into details to
spot the possible source of the problem. Interactive web terminals
bring the capability to connect to a running or completed job and
manually run commands to better understand what’s happening in the
system.
Improve includes in .gitlab-ci.yml for reusing scripts
Reusing CI/CD process code is a great practice to help ensure
consistency in software delivery, and minimizes the amount of per-job
scripting that’s needed to write and maintain. We now offer a flexible,
powerful approach for code reuse in templates using YAML extends
keywords.
Include private contributions in user contribution graph
At GitLab, we love open source! But sometimes you want to work on a private project you don’t
want to share (yet), or you are constrained for confidentiality reasons. In any case, GitLab has
got you covered.
With this release, we are introducing the option to include private contributions in your
profile’s contribution graph. Contributions to private projects are now displayed in the
contribution graph and contributions of this day if you enable this setting for your profile.
This way, your active work on private GitLab projects is represented accurately, without
giving away any private details.
Thank you George Tsiolis for your contribution!
Redesigned project overview
Iterating on our user interface is a constant focus for improving our product.
With GitLab 11.3, we are updating the UI of the project overview page to allow for a better
experience when exploring projects. Besides improving the overall information structure of
this page, we are left-aligning the top header section and optimizing the vertical spacing, so
you can get a quicker overview about the project and its content.
Protected Environments
Operators are often responsible for the sensitive task of protecting the environments we
deploy code to on a daily basis. This task becomes particularly important when deploying
code to a production environment.
With Protected Environments, operators obtain full control around which person, group, or account
is allowed to deploy to a given environment, allowing further protection and safety of sensitive
environments.
Code Owners
Code review is an essential practice of every successful project, but
who should review the changes is not always clear. GitLab now supports
assigning code owners to files to indicate the team members responsible
for code in your project.
Code owners are assigned using a file named CODEOWNERS, a format
similar to gitattributes,
and are listed below the commit details when viewing a file in GitLab.
In upcoming releases, Code Owners will be integrated into the merge
request workflow to
suggest approvers,
assign approvers,
and enforce code owners.
Epic forecasting with integrated milestone dates
Prior to this release, you could set fixed values for the planned start
date and the planned end date of an epic. This is useful for high-level
planning of epics, and tracking them over time. However, as issues are
attached to the epic, and the issues are scheduled for work with actual
milestones, it would be useful to have the epic dates reflect those milestones.
With this release, you can easily switch from the fixed value for either of
the dates, to a dynamic value called From milestones. For the planned
start date, this dynamic value will take on the earliest start date of all
milestones assigned to the epic’s attached issues. This is truly dynamic
in that it will change if issues are added or removed, if milestones are
assigned or unassigned (to those issues), or if the start dates are changed
for those milestones. The dynamic version of the epic’s planned end date
is analogous.
This feature is useful if you want to seamlessly transition from high-level,
top-down planning to micro-level, bottom-up planning. See more in a
blog post on the Epics roadmap that we published
about this a few weeks back.
Other improvements in GitLab 11.3
New epic event as custom notification
In a previous release, we provided email notifications for new epics,
for users who have configured their group-level notifications to the
Watch level. With this release, we are adding more customization.
You can now configure this event trigger on or off using the Custom notification
level, along with other event triggers.
Allow self-approval of merge requests
The user who creates a merge request may not be the author of the
changes, and other users may add additional changes to the merge
request after it is opened. Maintainers can now allow self-approval
of merge requests from the project settings.
Previously, the user who opened the merge request was assumed to
implicitly approve the merge request and was therefore excluded from
approving the merge request. There are many situations where this is
not true. Allowing self-approval removes this assumption.
Custom file templates for self-managed instances
File templates for LICENSE, .gitignore, Dockerfile and
.gitlab-ci.yml files make it easy to add these common files to
projects. Custom file templates can now be added to self-managed GitLab
instances by selecting an instance-wide template repository which
contains your templates.
Custom templates are useful when the templates provided by GitLab are
too generic, for example a custom license that should be used for every
project in the company, or a complex Dockerfile that should be used
for every microservice.
Thank you Daniel Barker for
contributing
custom license templates.
Define project name when creating a new project
To add a project name to your newly created GitLab project, you previously had to go into the
project settings and overwrite the project slug with a proper name.
With GitLab 11.3, we are adding the project name field to the “Create project” form. In addition,
the project slug is now automatically generated from the project name, while still allowing
you to adjust this field. This improvement makes the process of creating a new project faster
and more straightforward.
SAST support for Groovy
Static Application Security Testing is responsible for spotting vulnerabilities in your
source code as soon as it is committed to the repository, looking for known patterns
and common errors that may lead to security flaws in the final application.
That’s why each different language needs specific support.
With GitLab 11.3, we introduce Groovy
in the list of languages supported by GitLab SAST. Projects using this language are
now automatically detected and you don’t need to change anything to your code or your
pipeline definition to enable this feature. Auto DevOps is also supporting it as part
of its default configuration.
Alerts for library metrics
In GitLab 11.2, we added the ability to set alerts for custom metrics, which allowed developers to be notified
in the event of any issues with their applications.
With GitLab 11.3, we have now extended support for alerts to all metrics, including the metrics that
are provided by default with our library metrics.
Geo improvements
We continually focus on improving our Geo feature for distributed teams. Some of the noteworthy improvements in GitLab 11.3 include:
You can also read about how we built GitLab Geo.
Gitaly v1.0
Git access for regular usage of GitLab can now occur entirely through
Gitaly, GitLab’s gRPC service to access Git. This means it is possible
to run Gitaly on its own server without NFS when all optional feature
flags are enabled.
In the upcoming Gitaly v1.1
release all feature flags will be enabled by default, and the last
few remaining features will use Gitaly, removing the need for NFS.
Read our blog post about
the road to Gitaly v1.0.
GitLab Runner 11.3
We’re also releasing GitLab Runner 11.3 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.
Omnibus improvements
- GitLab 11.3 includes Mattermost 5.2,
an open source Slack-alternative which includes an
upgraded plugin system, ability to search archived channels, Romanian language
support, and much more. Since it includes
security updates, upgrading is recommended.
gitlab-elasticsearch-indexer has been updated to 0.2.2.omnibus-ctl has been updated to 0.6.0.- The Redis tcp_backlog and
HZ
settings are now configurable, as well as
max_concurrency
in sidekiq_cluster.
- The default maximum memory Sidekiq can use is now 2GB.
- SSL compression has been disabled by default for
gitlab-psql and gitlab-geo-psql.
Quick action to add issue to epic (from issues)
Adding an issue to an epic (or removing an already attached issue) is easily
done from the epic page itself. This is useful for when you are already
working in an epic.
But sometimes you are working in an issue, and know that you want to attach
it to an existing epic that you know about. You can now do so with a simple quick
action on the issue page by pasting in the epic URL. In a future release,
you’ll even be able to search for the epic in the quick action command via
autocomplete.
Additionally, another issue quick action will allow you to remove it from
an already attached epic.
Display repository languages on project overview
The code languages of which a repository consists is relevant information when exploring GitLab
projects.
With this release, we are adding a code languages bar to the project overview, showing all
relevant languages the repository consists of, including their relative quantity.
File templates in the Web IDE
File templates for LICENSE, .gitignore, Dockerfile and
.gitlab-ci.yml make it easy to add these common files to projects,
and can now be used in the Web IDE. File templates in the Web IDE makes
it easier to start a new project in the Web IDE and keep these
important files up to date.
Store Wiki uploads in the Wiki repository
Images uploaded to the wiki through the wiki editor are now stored in
the Git repository. This means images will now be display when
previewing a wiki locally using Gollum.
Previously, images were stored in the project uploads directory with
attachments uploaded to issues and merge requests. This prevented wikis
from being previewed locally or being migrated to a different Git
repository.
Filter webhook push events by branch
Webhooks for push events make it easy to automatically notify external
services of new commits, but all branches are rarely of equal
importance. Push events can now be filtered by branch so that
external services are only notified about the changes that matter to
you.
Previously webhooks could not be filtered by GitLab, and most external
systems do not have a feature filter incoming events. This meant it was
not possible to integrate these services directly with GitLab if you
only wanted a subset of push events to be used by the external service.
Thank you Duana Saskia for your
contribution!
Auto DevOps enabled by default
Auto DevOps was made generally available in GitLab’s 11.0 release and while it has
had great adoption, we want all GitLab users to take advantage of its great features.
From Auto Build to Auto Monitoring, Auto DevOps brings valuable benefits out of the box.
Starting with GitLab 11.3, Auto DevOps will be enabled by default on both GitLab.com and on
self-managed instances, so that every project can take advantage of its features.
Read through the documentation on enabling/disabling Auto DevOps if you wish to disable it for your project or for an entire instance.
Automatically disable Auto DevOps for project upon first pipeline failure
At GitLab, one of our product values is to default to on.
When we introduce a new configurable feature we know to be of great value, we will
default to ON so that everyone can benefit from it. While Auto DevOps supports
projects using the most popular programming languages, there may be some specialized
projects for which additional configuration is required.
Because we want to ensure we will not be running Auto DevOps pipelines for projects
that are not supported, we will disable Auto DevOps automatically if one of its pipelines fails.
GitLab will notify the project owner of this attempt so they can make the necessary
configuration changes to work with Auto DevOps if desired. Once the necessary changes are made,
project owners can re-enable Auto DevOps.
List of open source software components used by GitLab now available online
Starting with GitLab 11.3, we are making the list of open source software used by
GitLab more easily available. Prior to this release, it was available in each of our
Linux packages, but that required downloading and extracting the contents.
We are now publishing this content online, so it is easier to access and link to.
The list is available for GitLab CE and GitLab EE.
Some of the more noteworthy performance improvements in GitLab 11.3 include:
Deprecations
Support for Docker Versions in GitLab Runner
With GitLab 11.4 (October 22, 2018), support for Docker versions before 1.12 (API version 1.24) will be deprecated in line with
Docker’s latest version recommendation guidance. Beyond
the 11.4 release these older versions will no longer be officially supported and could stop working at any time.
Deprecation date:
October 22, 2018
Upgrade barometer
To upgrade to GitLab 11.3 from the latest 11.2 version, no downtime is
required. To upgrade without downtime, please consult the
documentation on downtimeless upgrades.
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 nine minutes and post-deploy
migrations amounted for a total of around 15 minutes. Background
migrations on the other hand are Sidekiq jobs that will run synchronously,
for this release we expect the migrations to take rougly 90 days to
complete on GitLab.com. The migration modifies all build-artifact
information to a new format.
GitLab Geo users, please consult the documentation on
upgrading Geo.
Changelog
Please check out the changelog to see all the named changes:
Installing
If you are setting up a new GitLab installation please see the
download GitLab page.
Updating
Check out our
update page.
Questions?
We'd love to hear your thoughts! Visit the GitLab Forum
GitLab Forum
and let us know if you have questions about the release.
GitLab Subscription Plans
GitLab is available in
self-managed
and
cloud SaaS
options.
Self-managed: Deploy on-premises or on your favorite cloud platform.
- Core: For small teams, personal projects, or GitLab trials with unlimited time.
- Starter: For co-located teams with few projects who need professional support.
- Premium: For distributed teams who need advanced features, high availability, and 24/7 support.
- Ultimate: For enterprises that want to align strategy and execution with enhanced security and compliance.
Cloud SaaS - GitLab.com: hosted, managed, and administered by GitLab with free and paid subscriptions for individuals and teams.
- Free: Unlimited private repositories and unlimited collaborators on a project. Private projects get access to Free features, public projects get access to Gold features.
- Bronze: For teams that need access to more advanced workflow features.
- Silver: For teams that need more robust DevOps capabilities, compliance and faster support.
- Gold: Great with many CI/CD jobs. Every public project gets the features of Gold for free irrespective of their plan.
