Running a given job only when dealing with a merge request is now easy.
merge_requests value with
only/except keywords will allow
you to configure jobs to run only (or except) when in the context of a
merge request. This allows finer control over pipeline behavior, and
also allows access to new environment variables indicating the target
branch and merge request ID when relevant, offering opportunities for
implementation of other more advanced behaviors.
Collaborating on merge requests is now easier – no more copy/pasting to accept a suggested change. Changes can now be suggested when leaving a comment on a merge request diff and accepted with a single click.
Changes can be suggested when commenting on a diff in a merge request, and accepted by any user with write permissions to the source branch.
This feature is available on GitLab.com today, and can be enabled
for self-hosted GitLab instances using the
flag. It will be
enabled by default for self-hosted instances in GitLab 11.7.
The Web IDE makes it faster and easier to contribute changes and resolve merge request feedback by eliminating the need to stash changes and switch branches locally. Yet, without a terminal to run tests, experiment in a REPL, or compile your code, making large changes is difficult.
From the Web IDE, you can now launch a Web Terminal so that you can work
in an editor side by side with a terminal, just like you would locally, to
inspect API responses or check your syntax in a REPL. The Web Terminal
is the first server-side evaluation feature of the Web IDE and is
configured using a new
Interactive Web Terminals are not yet available on GitLab.com. You can follow progress here. Changes are not currently synchronized between the editor and the web terminal. In an upcoming release, we will add support for mirroring changes and live preview.
With GitLab 11.6, we are happy to announce this functionality is now available for groups as well. By creating a sub-group within a new group setting, projects in this sub-group become available as templates. This streamlines the setup and ensures consistency across your projects, especially in larger group structures, such as microservice architectures.
Often, development teams working on related projects need to use the same Kubernetes cluster to deploy their applications. Starting with GitLab 11.6, users are able to create a group-level Kubernetes cluster that can be used for all projects contained within the group or sub-groups.
This will greatly reduce the time/effort required to configure infrastructure for your projects and allow you to focus on developing great applications.
Securing applications is critical for production-grade deployments. Cert-manager is a Kubernetes-native certificate management controller that will automatically issue and renew SSL certificates using Let’s Encrypt.
Using this SSL certificate will enable HTTPS for applications served via Auto DevOps as well as for JupyterHub deployments.
The Group Security Dashboard is the primary tool where Security professionals can manage vulnerabilities in their projects. One of the most important requirements is to know how the number of vulnerabilities is changing day by day, and understand if the team is solving problems quickly enough.
With GitLab 11.6, the Vulnerability Chart for Group Security Dashboards enables you to easily view the graph of vulnerabilities from the last month. For each severity level, you can read values for vulnerabilities and move over the chart to see more details about a specific point in time.