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.
Thank you blackst0ne for your contribution!
See the documentation on Squash and merge
Open projects in Xcode
At WWDC earlier this month, Apple announced their Xcode integration with GitLab, which makes it easier to work with your Xcode projects hosted in GitLab.
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.
See the documentation on opening in Xcode
Roadmap date ranges
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.
See the documentation on Roadmap date ranges
Unlimited Guests for free in Ultimate
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.’
See the documentation on guest permissions
Issue Board assignee lists
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.
See the documentation on Issue Board assignee lists
Assign ancestor group milestones
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.
See the documentation on Milestones
Issues and merge requests from subgroups in API
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.
See the documentation on GitLab APIs
Persistent Auto DevOps deploy tokens for Kubernetes
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.
See the documentation on deploy tokens for Auto DevOps
Specify deployment strategy from Auto DevOps settings
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.
See the documentation on Auto DevOps deployments
Variables defining deployment policy for canary environments
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.
See the documentation on the deployment policy for canary environments
Always-on approvals
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.
See the documentation on Merge request approvals
Fetch cluster parameters from GKE
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.
See the documentation on Adding and creating a new GKE cluster via GitLab
Disable Auto DevOps jobs with variables
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.
See the documentation on Auto DevOps environment variables
LFS files included when importing a project
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.
See the documentation on importing projects
Operations tab
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.
See the documentation on GitLab CI
SAST for .NET and Scala
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.
See the documentation on SAST
Cloud-native GitLab Helm chart now Beta
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.
See the documentation on GitLab Helm chart
Easily deploy and integrate JupyterHub with GitLab
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.
See the documentation on deploying JupyterHub
Expanded Issue Weight values
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.
See the documentation on Issue Weights
Combined system note for successive issue description updates
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.
See the documentation on Issues
View Kubernetes pod logs
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.
See the documentation on Pod Logs
Master role renamed to Maintainer
At GitLab, we are striving to build an inclusive culture. And so even within GitLab the product, we’re seeking ways to reflect that.
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.
See the documentation on Permissions
Label lists redesign
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.
See the documentation on Labels
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.
See the documentation on Issues API
Regex support for variables expressions
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.
See the documentation on regex support for variables expressions
Get GitLab Runner IP address via the API
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.
Thank you Lars Greiss for your contribution!
See the documentation on GitLab Runner APIs
GitLab Runner 11.0
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.
Key changes in this release include:
The list of all changes can be found in GitLab Runner’s CHANGELOG.
See the documentation on GitLab Runner
Improved deprecated configuration detection
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.
See the documentation on Omnibus GitLab
Geo improvements
We continously improve our Geo feature for distributed teams. Some of the noteworthy improvements in GitLab 11.0 include:
See the documentation on Geo
Project-specific pipeline ID
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.
See the documentation on predefined CI/CD variables
Omnibus improvements
- 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.
See the documentation on Omnibus GitLab
Open projects in Xcode
At WWDC earlier this month, Apple announced their Xcode integration with GitLab, which makes it easier to work with your Xcode projects hosted in GitLab.
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.
See the documentation on opening in Xcode
Unlimited Guests for free in Ultimate
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.’
See the documentation on guest permissions
Assign ancestor group milestones
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.
See the documentation on Milestones
Persistent Auto DevOps deploy tokens for Kubernetes
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.
See the documentation on deploy tokens for Auto DevOps
Variables defining deployment policy for canary environments
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.
See the documentation on the deployment policy for canary environments
Fetch cluster parameters from GKE
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.
See the documentation on Adding and creating a new GKE cluster via GitLab
LFS files included when importing a project
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.
See the documentation on importing projects
SAST for .NET and Scala
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.
See the documentation on SAST
Easily deploy and integrate JupyterHub with GitLab
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.
See the documentation on deploying JupyterHub
Combined system note for successive issue description updates
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.
See the documentation on Issues
Master role renamed to Maintainer
At GitLab, we are striving to build an inclusive culture. And so even within GitLab the product, we’re seeking ways to reflect that.
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.
See the documentation on Permissions
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.
See the documentation on Issues API
Get GitLab Runner IP address via the API
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.
Thank you Lars Greiss for your contribution!
See the documentation on GitLab Runner APIs
Improved deprecated configuration detection
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.
See the documentation on Omnibus GitLab
Project-specific pipeline ID
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.
See the documentation on predefined CI/CD variables
