Error tracking with Sentry
Error tracking with Sentry
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.
Create Pages sites in one click using bundled templates
Create Pages sites in one click using bundled templates
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 support for subgroups
Pages support for subgroups
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.
Merge Request Approval Rules
Merge Request Approval Rules
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.
Improved cross-project pipeline triggers
Improved cross-project pipeline triggers
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.
Improved squash commit messages
Improved squash commit messages
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 support for environment-specific custom domain
Auto DevOps support for environment-specific custom domain
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. <ENVIRONMENT>_ADDITIONAL_HOSTS.
Thank you Aaron Walker for the contribution!
Show function scale for Knative functions
Show function scale for Knative functions
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.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback