In this release, we are introducing a moderation feature to lock down continued discussion in an issue or merge request. This is useful when there is abuse or spam or you simply want to direct users to a different place in GitLab (another issue, for example) for continued feedback and collaboration. A project member with master access (or higher) has permissions to lock and unlock them. When an issue or merge request is locked, only project members can create new comments or edit existing ones.
Forks and merge requests are a great alternative to branch-based workflows as they enable any developer to create an alternative copy of the repository rather than committing changes directly against the primary codebase.
However, this means that it can make it harder for multiple people to work on the same code at the same time as the forks are isolated.
With GitLab 10.1, you can now create merge requests between forks of a canonical repository.
This makes working together on forks now much simpler, allowing multiple developers to easily review and merge across forks, bringing the code together before sending a merge request back to the canonical repository.
As part of our growing Enterprise authentication capabilities, GitLab 10.1 supports the ability to synchronize LDAP groups to GitLab based on filters, including user attributes.
For larger and more complex LDAP implementations there may be additional metadata in LDAP to infer permissions, roles, or types of users. By leveraging group filters, GitLab makes it easier to perform more user management capabilities directly from LDAP.
GitLab EES already allows basic synchronization of LDAP groups to GitLab groups. This is great functionality for basic LDAP integration, but means that your LDAP structure needs to effectively mirror GitLab’s group structure.
The introduction of LDAP Group Sync Filters in GitLab EEP means that your existing LDAP structures and attributes can be utilized in a more powerful way to manage your GitLab permissions.
Controlling and verifying identities are a key component to GitLab’s Enterprise authentication features. GitLab 10.1 introduces two new mechanisms to enforce user identity management whilst committing code.
Authors may be verified through GPG integration introduced in GitLab 9.5. With GitLab Enterprise Edition Premium it is now possible to enforce verification and reject any commits that are unsigned using push rules.
Every application needs a home and in case of web apps or microservices, it can be a Kubernetes cluster that can also deploy Review Apps during the development cycle. But setting up a cluster properly is not an easy task, and developers should focus on writing the code, rather than setting up the infrastructure.
That’s why, in GitLab 10.1, we add the ability to connect your Google Account to your projects and to create a brand new Kubernetes cluster on Google Container Engine (GKE) just by enabling the services for your account and specifying a few parameters. The cluster is immediately ready to use and can be leveraged, among others, by Auto DevOps to have your apps live.
As many projects rely on GitLab for automated testing, developers also need to access the test results in order to fully benefit of the feedback. This is just an example of how important it is to render HTML reports and make them accessible in an easy way.
With GitLab 10.1, we introduce the online visualization of HTML files created by pipelines for public projects, just one click away from the artifacts browser view. Your test reports, code quality and coverage information are now very simple to access directly from your browser, with no need to download them locally.