Analytics Workspace
Engineering and product teams can span multiple GitLab groups and projects, yet most of our analytics have traditionally been developed at the project level. This is why we created a workspace where users can aggregate insights across groups, subgroups, and projects.
The Analytics workspace will make it easier for teams and leaders to analyze and manage team metrics. The workspace will be available in Core. However, in some cases, specific features will be available to Enterprise Edition customers. As we move to the Analysis workspace, we will ensure that existing project-level analytics functionality is available to Community Edition users when moved to the new workspace.
In GitLab 12.3, we are releasing the first iteration of group and project level Productivity Analytics and group-level Cycle Analytics. In subsequent releases, we will enable the selection of multiple groups and subgroups; porting all analytics features for an instance. We would love your feedback and input on the strategy for Analytics/Value Stream Management
Design Management notifications
In GitLab 12.2 we released our initial iteration of Design Management. An important part of continuing to evolve is to ensure users are properly notified about these activities.
Conversations in designs will now create To-Do’s for mentioned users and send notifications based on their preferences. This helps to ensure that important feedback isn’t missed and can be actioned. In a future release, we’ll add those conversations to the main discussion tab for an easier conversation flow.
API for Merge Request Approval Rules
Approval Rules for Merge Requests allow you to 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 easily be spotted.
In GitLab 12.3, support for Approval Rules has been added to the API
for Projects and Merge Requests.
Keyboard shortcut for next and previous unresolved discussion
Reviewing, discussing and resolving feedback is the basis of code
review in GitLab. The Jump to next unresolved discussion button
makes it easy to quickly jump from discussion to discussion.
In GitLab 12.3, the new n and p keyboard
shortcuts to move to the next and previous unresolved
discussions in Merge Requests make it even more convenient to review
changes.
API to require merge request approval by code owners per branch
Using merge request approvals to restrict how code is pushed
to protected branches is helpful for promoting code quality and
implementing compliance controls. But not all merge requests
target stable branches, and not all stable branches need the
same controls.
In GitLab 12.3, it is possible to require code owners’ approval for specific
branches (through the API) to prevent directly pushing changes to files
with code owners, or merging changes without the code owners’ approval.
Note: This feature is only available via the API in GitLab 12.3. In GitLab 12.4
it will be available through the Protected Branch settings. Follow issue
#13251 for updates.
Flexible ‘rules’ keyword for controlling pipeline behaviors
Only/except rules in pipelines can have a lot of implicit behaviors, and
as more and more are added to your pipelines, it can become very difficult to
understand if a given job is going to run or not in different situations. We are
introducing a new rules: syntax that will make it much easier to implement and
understand complex rules. This syntax is optional and can exist in the same pipeline,
but not the same jobs, as the current only/except approach.
‘only/except: external_pull_requests’ for external repositories
GitLab CI has an “external repos” capability intended to allow customers to use external repos for source
control and GitLab for CI/CD. Until now, however, the CI_PIPELINE_SOURCE always showed push because it
was based on the pull mirror rather than the source external repo or webhook. This prevented GitLab
us from correctly supporting only/except: merge_requests-style options. In the 12.3 release
we’ve resolved this limitation.
Remove container images from CI/CD
The GitLab Container Registry allows users to leverage GitLab CI/CD to build and push images/tags to their project. Changes to the Container Registry are made by a service account called “CI Registry User” that is invoked from .gitlab-ci.yml with the predefined environment variable CI_REGISTRY_USER. Previously, this service account could push new tags to the registry, but it lacked permissions to untag images. This prevented branch-specific images from being removed, resulting in additional storage costs and creating difficulty when navigating the registry user interface due to the large number of additional, unneeded tags.
In 12.3 we have expanded the permissions of CI_REGISTRY_USER to allow for untagging of images so you can clean up branch-specific tags as part of your regular CI/CD workflow and use GitLab CI/CD to automate your cleanup scripts. This issue is part of a larger epic to lower the cost of the Container Registry by improving storage management.
Validate domains when performing full DAST active scans
You can now ensure DAST only performs active scans against
domains which are intentionally configured for DAST scanning.
This helps to ensure that DAST active scans are not
unintentionally run against domains which could be serving content
or being used in a production capacity.
There is no change to passive DAST scans, since passive scanning
does not potentially negatively impact scanned sites.
SAST Spotbugs analyzer updated for Java 11
The SAST SpotBugs analyzer has been updated to allow scanning of code
written with Java 11.
You can enable this by setting the SAST_JAVA_VERSION environment
variable in your project.
Run Pipeline button for Merge Request Pipelines
Pipelines for merge requests recently introduced a
new way to run a pipeline in the context of a merge request, but the only
way to trigger a new run of one of these pipelines was through a push. In this release we’ve added a button
to start a new pipeline, making it much easier to retry a failed pipeline.
User-defined CI variables available to docker build with Auto DevOps
CI variables allow you to tailor how processes are run to build your application as part of your CI pipeline. Starting in GitLab 12.3, you can extend the availability of user-defined CI variables to the docker build step in Auto DevOps. The data is made available as a new build secret value.
List one or more variables using the AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES
variable and it will be made available to use in docker build.
Knative for group and instance-level clusters
Group and instance-level clusters now support the installation of Knative,
the Kubernetes-based platform to deploy and manage serverless workloads. This will allow multiple projects
to make use of GitLab Serverless
features leveraging a single cluster.
Line charts for metrics dashboard
When it comes to visualizing metrics, oftentimes users would like to choose different types of visualization for specific metrics (e.g., line chart for CPU, area chart for disk space). To help achieve this, we added line charts as a part of our effort to enhance our dashboard offering around monitoring.
Quick actions to add/remove Zoom meetings on issues
Synchronous collaboration is a critical part of any fire-fight.
We are streamlining the number of steps it takes to spin up a conference bridge
and engage all required parties by embedding this functionality, using Zoom, directly
in an issue.
Once a user has started a Zoom meeting, they can attach it to an issue using a quick action
and inputting the Zoom meeting URL (e.g. /zoom https://gitlab.zoom.us/s/123456). A button will appear at the top of the issue giving users
direct access to the conference bridge. When the incident has resolved, the Zoom meeting can be
removed using /remove_zoom.
This feature is generally available on GitLab.com and feature flagged for use on self-managed instances. If you are interested in taking advantage of this feature for your self-managed instance of GitLab, operators can enable the issue_zoom_integration feature flag. In next month’s release of GitLab 12.4 we plan to remove the feature flag and make the Zoom Issue integration generally available for all self-managed users.
Geo displays secondary lag when pushing via Git HTTP
Fetching large amounts of data can take a long time for users in remote locations.
Replicating repositories with Geo reduces the time it takes to clone and fetch large repositories
by creating read-only secondary nodes near remote user. Because secondary nodes lag behind
the primary node, GitLab now provides an estimate of replication lag whenever git push is used over HTTP. This raises the visibility of using a Geo node and allows users to detect increases in replication lag and report them to systems administrators.
Because of protocol limitations, this message is not available when using git pull.
Disable 2FA for selected OAuth providers
Organizations using enforced two-factor authentication and an identity provider also using 2FA may find the requirement to authenticate twice frustrating. Thanks to a community contribution, you’re now able to bypass 2FA for selected OAuth identity providers in GitLab. For those using providers that handle 2FA, this makes logging into GitLab a friendlier and easier experience.
Thanks to dodocat for the contribution!
IP address restriction supports multiple subnets
Iterating on restricting group activity by IP address, GitLab 12.3 introduces the ability to specify multiple IP subnets. For geographically distributed organizations, this helps this feature shine; instead of specifying a single (and overly permissive) range, large organizations can now restrict incoming traffic to their specific needs.
GitLab Runner 12.3
We’re also releasing GitLab Runner 12.3 today! GitLab Runner is the open source project
that is used to run your CI/CD jobs and send the results back to GitLab.
Changes include:
List of all changes can be found in GitLab Runner’s CHANGELOG.
Performance improvements
We continue to improve the performance of GitLab with every release
for GitLab instances of every size.
Some of the improvements in GitLab 12.3 are:
Design Management status and discussion counts
In GitLab 12.2 we released the first iteration of Design Management, which allowed uploading designs directly to issues. They were uploaded in a separate tab within issues and the activity in each version of Designs wasn’t clear to the user. Now, when designs are uploaded, status icons are added in each version to let you know if it’s a new design or a change to an existing design.
We also added discussion counts on designs to better inform users of conversations happening. We’re excited about these additions to Design Management to help improve the collaboration and conversation inside of GitLab for design and engineering teams.
Compress Git ref advertisements over HTTP
When fetching changes to a Git repository, the Git server advertises a
list of all the branches and tags in the repository. This is called
ref advertisement and can be many megabytes for large projects.
In GitLab 12.3, when fetching over HTTP, the ref advertisement will be
compressed for supported clients reducing the amount of data being
transferred and making fetch operations faster.
On an average weekday, GitLab.com serves about 850GB of ref
advertisements over HTTP. After enabling ref compression, bytes
transferred has decreased by approximately 70 percent.
Audit logs for Git Push events (Beta)
Git history can be rewritten to change commits, authors and timestamps,
which makes it possible to craft clear and useful history for future
developers. For audit, this is a problem.
In GitLab 12.3, Git push events that add commits, rewrite history or
otherwise modify the repository can be added to the audit log. Audit
logs for push events are disabled by default to prevent performance
degradation on GitLab instances with very high Git write traffic.
In an upcoming release, Audit Logs for Git push events will be enabled
by default. Follow #7865 for updates.
Smarter Web IDE default commit options
Previously the Web IDE defaulted to Commit to current branch when making a commit. This made it easy for those with permissions to accidentally push changes to master or other protected branches. Now when making changes in the Web IDE, the default commit options are smarter to prevent making changes to the wrong branch.
Smarter commit options prevent accidental pushes to master and protected branches for users with write access. When the user has no write access, additional details are provided as to why options are unavailable. Additionally, the new commit options also support commits to a non-default branch with or without an existing Merge Request.
Per-job timeouts for CI/CD pipelines
Different jobs have different execution characteristics and may need different timeouts
to be set on a per-job basis. Timeouts can be configured by adding the timeout: keyword to your job in .gitlab-ci.yml, along with a number to indicate the number of minutes to wait before the job fails.
Thanks to Michal Siwek for the contribution.
‘interruptible’ keyword to indicate if a job can be safely canceled
The new interruptible keyword can be used to indicate whether or not a job should be canceled
if made redundant by a newer run of the same job. The keyword defaults to false, so it should
be used to specify jobs that are safe to stop. This value will only be used if the automatic cancellation of redundant pipelines
feature is enabled.
This helps avoid duplication of unnecessary jobs across your pipelines, reducing
costs and making your pipelines more efficient.
Due to a bug in the Runner, some executors do not stop in-progress jobs when cancelled. This is planned to be fixed in 12.4.
Status checking for pipeline triggers
We’ve recently improved the way cross-project pipelines can trigger
each other, but one thing still missing was having the triggering pipeline
wait or confirm success of the triggered pipeline. It was possible using
API polling, but in this release we’ve introduced the depends and wait
strategies where this can be handled automatically for you. If you are triggering
a pipeline you want to depend on, it will wait for the pipeline to complete
and will verify it succeeds before finishing the triggering job. If you choose
wait, it will wait for it to finish but proceed regardless of pass/fail status.
API endpoint to list the Docker images/tags of a group
The GitLab Container Registry allows users to build and push Docker images/tags to their project from the command line, CI/CD, or from an API. However, until GitLab 12.3 we did not offer any visibility into images/tags at the group level, a popular request from users.
We have added two API endpoints that will give visibility into which images and tags exist at the group level. This is the first step in helping improve visibility and discoverability for the Container Registry. Next, we’ll leverage the API to create a group-level browser as part of the Container Registry user interface.
SAST scanning without Docker-in-Docker
SAST scans can now optionally be done without using Docker-in-Docker.
This means SAST scanning can be configured to not need elevated
privileges.
Edit vulnerability dismissal reasons
Vulnerability dismissal reasons can now be edited and deleted.
This allows you to add and update context for a vulnerability as you
learn more over time.
Improve Pages initial setup experience
To improve the Pages user experience, we added a banner that notifies users of the possible initial setup time. We understand it can be frustrating to see the “Congratulations” message without the page being available. The banner helps make it more clear what to expect.
Show Kubernetes cluster used for deployment
The jobs detail page now displays the name of the Kubernetes cluster that was used for the
given deployment. Project owners and maintainers are presented with a link on the cluster name
which will link directly to the cluster details page.
JupyterHub for group-level Kubernetes clusters
Group-level clusters now support the installation of JupyterHub,
a multi-user service for easily launching notebooks as well as creating
runbooks for operators. This extends the availability
of JupyterHub to both project-level and group-level clusters.
Close issue via slash command in Slack
Chat tools are required during fire-fights to resolve modern IT incidents. This tool needs to be closely integrated
with the systems you are managing and the tools where you will actually perform remediation. As much as possible, you
want to minimize context and tool switching while you’re working to restore services and update your external stakeholders.
In 12.3, we have added an additional slash command to the suite of commands we offer with our ChatOps product based on Slack.
Issues can now be closed from Slack without needing to switch tools, just locate the issue in question, and manually close it.
You can close it from where you are working.
Geo natively supports Docker Registry replication
Geo natively supports replicating a Docker Registry
between primary and secondary Geo nodes. This allows Geo users to use a Docker Registry on a close-by secondary node. This approach is storage-agnostic and can be used
for object storage, such as S3, or local storage.
When using distributed object storage (e.g. S3) for a Docker Registry, the primary
and secondary Geo nodes can use the same storage type. This approach does not rely on Geo’s native replication ability.
API activity included in IP address group restriction
GitLab 12.0 saw the introduction of restricting a group’s activity by IP address. We’ve iterated on this feature to also include API activity, where incoming requests will be rejected if they do not adhere to the group’s restriction. This solves an important problem for compliance-minded enterprises with an extended approach to access control, covering both UI and API activity.
System hooks for project and group member updates
System hooks allow for powerful automation by triggering requests when a variety of events in GitLab take place. Thanks to a community contribution, project and group membership changes are now supported in system hooks. This is a terrific addition for those who are looking to build additional levels of oversight and automation over membership changes.
Thanks to Brandon Williams for the contribution!
S/MIME Email Signing
Notification emails sent by GitLab can now be signed with S/MIME for improved security on the instance level.
Thanks Siemens, @bufferoverflow, and @dlouzan for the contribution!
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