Keeping an eye on errors generated by your application helps maintain a good user experience by detecting problems before users report them and speeding up resolution when they occur.
GitLab 11.8 makes it more convenient and efficient to monitor errors by integrating with popular open source error tracker Sentry, and displaying the most recent errors right within your GitLab project.
Sentry has recently improved their GitLab integration, enabling detection of suspicious commits, release and commit tracking, and more. With the combination of both integrations you’ll have a simple path to Sentry from GitLab, as well as a clean way to get to GitLab from Sentry, so that you can always address errors contextually, staying within your existing workflow.
We are now bundling our most popular Pages templates directly in GitLab, opening up the possibility of creating your sites directly from the new project creation screen instead of having to fork a sample repository as before.
Check out our blog post about using GitLab Pages templates for more.
Pages have been updated to work with subgroups in GitLab, giving you the ability to create Pages sites there as well. Sites set up in this way will have a URL in the format of
toplevel-group.gitlab.io/subgroup/project. This will give your projects, even when part of subgroups, access to the ability to create documentation or other sites needed as part of releasing your software.
Code review is an essential practice of every successful project, but who should review the changes is not always clear. It is frequently desirable to have a variety of reviewers from different teams like Engineering, UX, and Product.
Approval Rules, new in GitLab 11.8, allow you to better communicate who should participate in code reviews by specifying the eligible approvers and the minimum number of approvals for each. Approval rules are shown in the merge request widget so the next reviewer can quickly be assigned.
In GitLab 11.3 we introduced Code Owners to indicate which team members are responsible for which code in your project. Code owners are integrated into approval rules so that finding the right people to review your change is always easy.
Approval Rules are disabled by default in 11.8 and must be enabled by an instance administrator by executing
Feature.enable(:approval_rules) in the rails console.
Approval Rules have temporarily been disabled on GitLab.com. We expect to be re-enabled after deploying GitLab 11.8.1. Follow this issue for updates.
Starting with GitLab 9.3, you’ve been able to create multi-project pipelines by triggering a downstream pipeline via a GitLab API call in your job. In 11.8, we’ve added first-class support for triggering these downstream pipelines with the
trigger: keyword, which can be added to a bridge job to automatically trigger a downstream pipeline when the current pipeline succeeds.
Creating Git history that is readable and useful to people in the future can be at odds with pushing small commits to fix a unit test or resolve feedback. Commit squashing combines all these commits into a single tidy change, but at the same time wipes out your thoughtful commit messages.
GitLab now defaults the squash commit message to the first multi-line commit message in the feature branch, and allows you to override the commit message so that you can update it to reflect any important changes.
Auto DevOps allows you to quickly get started by adding a “base domain” for your projects. When your application is ready for production deployment, you may then want to use a custom, fully qualified domain name.
You can now use the environment variable
ADDITIONAL_HOSTS to specify one or more custom domains for your application. Furthermore, you can scope it to a specific environment by prepending the environment name to the variable, ie.
Thank you Aaron Walker for the contribution!
Deploying functions using GitLab Serverless comes with all the benefits of Knative, such as scaling your serverless deployments up and down to zero.
You can now see the scale of your serverless deployments for each application or function deployed to your Knative instance. Scale is illustrated by the number of Kubernetes pods currently in use.