Todos for epics
Todos are a helpful personal productivity tool integrated directly into GitLab. When you
are @-mentioned in an issue or merge request, you get a dismissible todo object in GitLab
along with an email alert. And there are lots of other todo trigger events as well.
With this release, we are bringing todos to epics, similar to their availability in issues and merge requests.
When you are @-mentioned in an epic, you will get a todo for it, streamlining your personal workflows.
You can also create a todo manually from the sidebar when viewing an epic itself, again similar to the capability within issues and merge requests.
The API has also been updated so that you can access epic-triggered todos and
create a todo for an epic, all via the API itself.
Group milestones on dashboard milestones list page
Milestones in GitLab are useful for tracking work within an iteration or a sprint.
In particular, group-level milestones allow issues across several different projects
to be tracked together.
With this release, we are showing group milestones on the dashboard milestones page.
This means that users will now be able to see all milestones (both project and group
milestones) that they have access to in the GitLab instance, all in a single location.
All burndown charts available in GitLab Starter and GitLab.com Bronze
The burndown chart is a useful visualization for teams to track work as it is being completed
during a milestone. It allows teams to anticipate risks early on, and make adjustments to mitigate them
early in the cycle, rather than wait until the milestone is done.
Previously, for the group milestone page, the burndown chart was only available in GitLab Premium and
GitLab.com Silver. In this release, we’ve brought that feature to GitLab Starter and GitLab.com Bronze,
allowing more users to enjoy group-based use cases. This also simplifies the feature, since the
burndown chart on the project milestone page was already available with the Starter/Bronze tier.
Multiple Jira transition IDs for closing Jira issues from GitLab
Many teams using GitLab also use Jira as an issue tracker. GitLab has a Jira
integration that allows GitLab merge requests to automatically close a Jira
issue when the merge request is merged. This requires you to configure a
Jira transition ID in the GitLab settings, indicating how you want to transition
Jira issues into the closed state. But this also means you are limited to
only a single transition type on the Jira side.
With this release, we now support multiple Jira transition IDs. That means if
your Jira project is set up such that there are multiple ways to close a Jira issue,
you can have GitLab recognize all those ways, so that merging a GitLab merge request
will close the Jira issue, regardless of which state the Jira issue starts in.
Thank you lilinzhe for the contribution!
Importer for Bitbucket Server
While GitLab has supported importing projects from Bitbucket Cloud using OAuth authentication
for quite some time, such an integration with the self-managed Bitbucket Server wasn’t available.
Until now.
With GitLab 11.2, it is now possible to import your projects from Bitbucket Server to GitLab
with minimal effort. All that is required is to provide the server URL and your credentials.
GitLab then lists all your Bitbucket Server repositories, ready for import.
Approve and blacklist licenses
License Management automatically detects the software licenses that you
are introducing with your code and its dependencies. In previous versions
of GitLab, this feature kept you informed of all licenses, but did not
allow you to define a policy about the licenses that should be allowed
in your production code.
With GitLab 11.2, you can now define whether any license should be approved
or blacklisted for your application as soon as the relevant code is introduced
in a merge request. The merge request widget displays all new licenses
that have not yet been introduced into the target branch, and allows you
to define whether each should be blocked or allowed, going forward.
Show project ID on project overview
GitLab projects are associated with an auto-generated, unique project ID upon creation. This
information is available in the General project settings and via our API.
With this release, we have added the project ID to the project overview page,
so that users without Maintainer permissions also have access to this ID when needed.
Thank you Tuğçe Nur Taş for this contribution!
Google Hangouts integration
Chat applications work great together with GitLab, as a complementary way for teams
to communicate and get work done. In this release, we’re happy to merge
in a generous contribution from Kukovskii Vladimir to integrate Google Hangouts
into GitLab. With this feature configured as a project service, you can now
receive a variety of GitLab events as notifications directly within Hangouts.
Thank you to Kukovskii Vladimir for the contribution!
Instance-level analytics available for everyone
Analytics are an important tool for understanding activity on your GitLab instance.
Previously, two of these features – ConvDev Index and Cohorts – have
only been visible to admins.
Since these features provide useful (and anonymized) information on GitLab
usage, we are making them visible to all users, by default, behind a new
“Instance Statistics” section in the top navigation bar.
Visibility of this section is configurable, and can be set to admin-only.
Introducing instance-level statistics is our first step to democratize
analytics in GitLab, and we are excited to introduce more to this section
in the future.
Securely build Docker images with kaniko
Historically, building Docker images within a containerized environment has required compromises, using techniques
like docker-in-docker on
privileged containers.
These solutions are often insecure and slow.
kaniko
is a new tool developed by Google, which is able to securely build an image within an unprivileged container.
GitLab 11.2 and Runner 11.2 are now compatible with kaniko,
enabling usage with GitLab CI/CD and the integrated
Container Registry.
Switch branches in the Web IDE
In GitLab 11.2 you can now switch to any branch in the current
repository without leaving the Web IDE. The improved branch and merge
request switcher allows you to search the list of branches for the
current repository.
HTTP pull mirroring API
Pull mirroring for HTTP remotes is now available through the Projects
API. Pull mirroring makes it easy to keep forks and replicas up to
date, regardless of whether the repositories are on the same server.
Mutual SSL authorization for Helm Tiller
In order to improve the security of Kubernetes clusters integrated with GitLab,
we must ensure Helm Tiller is secured so that only the GitLab instance managing it
can deploy applications to its namespace.
Starting in GitLab 11.2, all new Helm Tiller applications that are deployed to
Kubernetes clusters via GitLab’s Kubernetes integration will be locked down using
mutual SSL authentication. This means no other clients outside of your GitLab instance
will be able to deploy applications, making your cluster more secure. Additionally, starting
with this release, we will be using Helm Tiller version 2.7.2.
GitLab Runner 11.2
We are releasing GitLab Runner 11.2 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.2 includes Mattermost 5.1,
an open source Slack-alternative whose newest release includes a new GIF selector, auto-linking plugin,
subpath support, plus much more. Since it includes security updates, upgrading is recommended.
gitlab-ctl repmgr now honors the directories set by postgresql['data_dir'].- GitLab’s Prometheus instrumentation now works out of the box on Docker containers.
git has been updated to 2.18.0.- Alertmanager has been updated to 0.15.1, gitlab-monitor has been updated to 2.18.0.
Summed weights in issue board list
Prior to this release, we already showed the issue counts at the top of each list in issue boards.
This is helpful if you are doing any type of planning or tracking in an issue board, to see how
many issues are in a particular workflow stage or assigned to a person in an assignee list.
With this release, we are extending that concept to show the summed weights of all issues in each list
alongside the issue count. This gives even more granularity to teams who use weights for effort
estimation. You can now see at a glance how much weight is in a list, and if you need to move issues
between lists to compensate for too much or too little weight, you can now do so and the summed
weights will update immediately. You don’t have to refresh the board.
Search labels in project labels list
Labels in GitLab are a versatile feature, allowing you to categorize issues, merge requests,
and epics. Teams use them for a variety of use cases, and it’s not uncommon for projects
to have many pages of labels. As a result, it’s often cumbersome to change a label name, its
description, or its color. You have to click through many pages to get to the label you care about
on the labels list page.
In this release, we’ve made that easier by providing a search feature in the project labels list
page itself. The search covers both the label title and description. So if you know the label title
or even know just what the label is about, you can quickly find it by typing a search term in the text box.
Service level indicator alerts for custom metrics
GitLab includes a fully integrated performance monitoring solution, providing an easy and seamless
way for engineers to view key metrics like throughput, error rate, and resource consumption. While it is
critical to be able to view these metrics when needed, it is also important to be able to be proactively
notified in the event of issues, to expedite a response.
GitLab 11.2 now provides the ability to easily create alerts for custom metrics directly from the dashboard,
with just a few clicks. Users can set the desired threshold, and when it’s exceeded for five minutes, email notifications
will be sent to maintainers and owners of the project. GitLab-provided metrics will be supported in a
future release.
Cloud native GitLab Helm chart generally available
We are excited to announce that the cloud native GitLab
Helm chart is now generally available (GA). 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. A GitLab Runner is also deployed,
making it easy to get started with GitLab CI/CD.
The gitlab chart is the best way to deploy GitLab on Kubernetes. Give it
a try and let us know what you think!
Private profiles
The user profile page on GitLab shows your activity, contributions, and personal projects.
While visitors only see detailed activity that they have permission to see,
such as your comments on public repositories, some users may prefer not to expose this information
in aggregate.
With GitLab 11.2, we introduce the option to disable activity-related information on your
profile, giving you more complete control over the information you share with the community.
Thank you JX Terry for your MVP-winning contribution!
License Management reports at the pipeline level
Once a new change has been introduced into the codebase, users may want
to know the updated set of licenses that apply to their application.
GitLab 11.2 brings the License Management report to the pipeline level,
so the current list of licenses can be accessed and users can check their
master branch directly.
Download individual repository files
When browsing through a project repository on GitLab, the need to download
a specific file frequently arises. Until now, this was only possible within
the GitLab interface by viewing the file in a new browser tab
and then saving it.
GitLab 11.2 introduces a new “Download” button in the file viewer interface,
available for each individual repository file, allowing you to
download any file directly from the application more easily.
Thank you Kia Mei Somabes for your contribution!
Support for Git SSH access via certificates
In large organizations, SSH keys may only be issued on a temporary basis
and be set to expire quickly. An alternative approach, available with
GitLab 11.2, is to use OpenSSH certificates which include all the information
about the user within the certificate. This removes the need for users
to generate and upload SSH keys.
Thank you Ævar Arnfjörð Bjarmason for your contribution!
Custom Wiki sidebar
When utilizing a Wiki in your GitLab project for extended documentation, the right sidebar shows
a hierarchical table of contents of your Wiki page structure by default. There are cases, however,
where you may want to provide additional content, extending this set of automatically listed pages.
With GitLab 11.2, we introduce an option to override the generated table of contents via your
own custom sidebar. By adding a _sidebar Wiki page, maintainers gain full freedom to define an
individual Wiki sidebar based on GitLab Flavored Markdown.
Thank you jsooter for your contribution!
Delete and rename files in the Web IDE
The Web IDE is the most convenient way to add and edit files in the GitLab
interface, but renaming and deleting existing files was not yet possible. In this
release, you can now delete and rename any file without leaving the Web IDE.
JUnit test summaries in merge request widget
It is very common for a pipeline to contain a test job that checks the latest code. If the tests fail,
the pipeline fails and users are notified. But they still want to dig into details about the
failed tests.
With the 11.2 release, it is now possible to see JUnit test results directly in the
merge request widget.
Built-in project templates now use Dockerfile
Our built-in project templates are now built using Dockerfiles instead of herokuish. For some
configurations this will result in performance improvement of build times, and is considered
a best practice that we want to illustrate in our templates.
Ability to manually stop an environment
Some CI/CD environments are disposable and unlikely to be reused in the future. One
clear example is when using Review Apps,
where a new environment is created dynamically on each branch. Up until
now, you could only stop an environment if you
defined it in .gitlab-ci.yml. With
GitLab 11.2, it is now possible to manually “stop” an environment from the UI
under the environments page.
Geo improvements
We continually focus on improving our Geo feature for distributed teams. Some of the noteworthy improvements in GitLab 11.2 include:
Performance improvements
Some of the more noteworthy performance improvements in GitLab 11.2 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