GitLab 11.2 released with live preview in the Web IDE and Android project import
19 - 24 minutes
We are super excited to deliver new features with 11.2 that will help you get started and iterate faster. Today we deliver enhancements to the Web IDE, support for manifest files to import Android projects, and enable custom project templates.
Preview changes in the Web IDE
In addition, with 11.2, you can delete and rename files and switch branches without ever leaving the Web IDE.
The Cloud Native Helm Chart is now generally available to help you more quickly install GitLab on Kubernetes. This chart features a more cloud native architecture, with a container for each component of GitLab and no requirement for shared storage. The result is 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.
Several other additions will help you and your teams handle projects more efficiently. With 11.2, GitLab administrators can offer instance-wide custom project templates, allowing users to start new projects quickly by automating repetitive setup tasks.
Client-side evaluation is powered by CodeSandbox. It can be enabled by an admin for self-managed GitLab instances and is already enabled for all projects on GitLab.com. Later this year we will add server-side evaluation powered by GitLab CI, allowing you to test and preview Ruby applications and more!
In today’s fast-growing development environment, moving from an idea to setting up a new project from scratch is still a tedious task. There’s not only a lot of boilerplate code involved, but also additional administrative overhead preventing your users from getting started right away.
Starting with this release, we enable organizations to manage their own project templates. As a GitLab admin, you can now define a group within your installation that serves as source for custom templates. All direct child projects of this group are available as templates when creating a new project.
All relevant repository and database information of a template are copied over to your new project, including the project and wiki repository, issues, project configuration, and more.
Collaboration is a core principle within the GitLab product. When using GitLab day-to-day, together with your colleagues and community, it can be helpful to communicate what you are up to, including your availability or current workload.
With GitLab 11.2, we are bringing status messages right to your personal profile! Within your profile settings, you can now add a status including an emoji and custom message. This status will show up on your profile page, as well as in comments and author titlebars, exposing your current status to everyone who is working with you.
As instances grow, projects and groups can multiply and become increasingly hard to find, so GitLab requires a powerful search experience. In this release, we’re taking a step forward to make search clearer, more consistent, and easier than ever to use.
In 11.2, we’re improving search by removing project and group scoping from the search bar. Instead of restricting search to the project/group you’re in, GitLab now gives you a consistent experience with the ability to search instance-wide from the top of every page.
We’ve also made search easier to use by showing group and project icons in the results, plus expanding the width of the search bar accordingly.
Until now, importing complex project structures with multiple sub-structures was a tedious, time-consuming task.
With this release, we introduce support for manifest files for project imports. A manifest XML file contains metadata for groups of repositories, allowing you to import larger project structures with multiple repositories in one go.
When creating a new project, there is a new option to choose a “Manifest file” as source of your project import on the “Import project” tab. In addition, you can select from the list of individual projects in a subsequent step if you don’t want to import the complete project structure.
Issue boards were originally designed to support workflow tracking with label-based lists. In GitLab 11.0, we introduced assignee lists to help teams see issues assigned to different team members and allow quick reassignments.
With this release, we are introducing a third type of list, the milestone list. All issues assigned to the given milestone will appear in a milestone list. This allows teams to see issues in different milestones all at once in a single board with multiple milestone lists. This also means you can quickly move issues across different milestones. With the summed weights feature also in this release, this is especially useful for teams who want to balance total issue weight across milestones, not over-scoping or under-scoping in a given milestone.
We’ve also updated the API so that you can now add and remove all three types of lists on a given board.
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.
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.
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.
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.
While GitLab has supported importing projects from Bitbucket Cloud using OAuth authentication for quite some time, such an integration with the self-hosted 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
In previous versions, it was possible to configure GitLab’s SAML and Bitbucket integrations even when OmniAuth – which both integrations require – was disabled on the instance. (Note that OmniAuth is disabled by default for new installations.) We have now streamlined this behavior in that both integrations are unavailable when OmniAuth is disabled.
Removal date: August 22, 2018
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.
Removal date: October 22, 2018
GitLab Pages IP on GitLab.com - DNS A records must be updated
On August 11, GitLab.com migrated from Azure to Google Cloud Platform and with it, GitLab Pages websites also live in a new place. For this reason, GitLab.com users who have configured a custom root domain for their Pages sites using a DNS A record must update their records from 22.214.171.124 to 126.96.36.199. Meanwhile, there is a proxy in place to keep your websites up and running using the old IP address through Monday, October 22.
We had changed the Pages IP on GitLab.com in the past, and the steps you need to follow are the same as those detailed in this blog post, with the exception of the new IP itself. We plan to forward the old IPs for the foreseeable future, but strongly advise you to update your DNS A records immediately, otherwise, from October 23 onward, your websites may not be available until you make this change. Note that DNS CNAME records do not need to be changed. GitLab self-hosted instances are not affected by this change.
This section will be updated if any additional information is posted.
For this release we have migrations, post-deploy migrations, and to help with larger migrations, we have introduced background migrations.
GitLab.com migrations took approximately 25 minutes and post-deploy migrations amounted to a total of around 1 minute. Background migrations on the other hand are Sidekiq jobs that will run synchronously. For this release, these migrations took less than a day to complete, and no side effects were expected nor present. These target completed pipeline builds. Pipelines executed after upgrading are not affected.
GitLab Geo users, please consult the documentation on upgrading Geo.
If you are using Advanced Global Search, please be advised that a re-index is necessary in order to fix a bug that would cause some Note types to not be indexed.