Audit events for changes to protected branch settings
GitLab now records additional audit events when changes are made to protected branches.
Specifically, events are now created when changes are made to:
- Who is allowed to push to the branch.
- Who is allowed to merge to the branch.
- Whether or not code owner approval is required.
- Whether or not force pushing is allowed.
This enables you to have more visibility into what is going on in GitLab and
ensure that controls have been put in place and that they have not been changed. This
can help to ensure you successfully pass audits that require separation of duties.
When controls
have been changed, the audit events will help you see when and who made the change
to dig deeper and understand why.
Thanks to Adrien Gooris from Michelin for this contribution!
Filtering for project-level Value Stream Analytics
Value Stream Management for projects just got better. Now you can filter the work items in a stage by milestone, label, author, or assignee to view stage times for the issues and merge requests you are most interested in.
OAuth access tokens issued with expiration by default
By default, any OAuth access tokens issued after this release will have a 2 hour expiry window. Previously, OAuth access tokens never expired, which is insecure. You can disable this option by unchecking the Expire Access Token checkbox on the OAuth application UI.
Filter roadmap view by set dates
When you view your team’s progress over a large timeframe, the horizontal nature of the roadmap canvas adds a ton of horizontal scrolling.
With this release, you can reduce the infinite scrolling interactions by using the predetermined date range options in the top left of the roadmap search bar. You can jump to the dates you need and the roadmap quickly zooms in on your area of interest.
Filter pipelines in Pipeline view by source
The project pipelines list at CI/CD > Pipelines shows all pipelines for a project, but you could not filter the list by pipeline source. Now, in GitLab 14.3, you can easily filter the pipeline list based on sources like api, schedule, merge_request_event, and so on.
GitLab Runner on IBM POWER9 (Linux OS)
If you use IBM POWER9 (ppc64le compute architecture) systems for compute-intensive workloads, you have not had runners available from GitLab. You’ve had to rely on your own runner, or on a runner built and maintained by IBM. While this allowed you to run your GitLab CI/CD jobs on POWER9, it was less than ideal. The binary was not part of the GitLab Runner release and support lifecycle. You can now install and use a runner built and supported by GitLab to execute GitLab CI/CD jobs on IBM POWER9 (Linux OS).
New API available for the Dependency Proxy
To reduce build times, avoid Docker Hub rate limits, and reduce your external dependencies, you can use the GitLab Dependency Proxy to proxy and cache container images from Docker Hub.
Previously, you had no way of knowing how the Dependency Proxy was being used. For example, for your GitLab group, maybe you wanted to know how many container images were added to the cache, or you wanted to view details about items already in the cache.
Now you can use the GitLab GraphQL API to quickly find these important details. You can use the new API to uncover details about the images and their underlying components, so that you can know for certain which container images and tags are being used in your group.
Next up, we’ll use the new API to deliver a significant update to the user interface. GitLab issue 250865 proposes an update to the UI to add helpful metadata for quick reference.
GitLab Pages support splat (wildcard) and placeholder redirects
GitLab Pages supports a variety of redirect rules, including redirects and rewrites. In this release, you can now also use splats (aka wildcard) and placeholders to redirect your Pages content to specific pages.
Geo replicates Pages deployments
With GitLab Pages, you can publish static
websites directly from a repository in GitLab. In a disaster recovery scenario, it was already
possible to regenerate Pages sites after failing over to the new primary site. However, Geo
now also replicates Pages deployments. This provides extra protection against data loss
and reduces recovery time by removing the need to regenerate Pages after a failover.
GitLab chart improvements
- We have removed the extra Ingress path for the Sidekiq administration panel, after addressing the original need. This resolves several complications with external Ingress providers, such as Google’s GCE and Amazon’s ALB.
License Compliance now supports Java 15
License Compliance now supports Java 15 projects. Set the variable LM_JAVA_VERSION to 15 in order to utilize this Java version for your project.
Audit events for merge request approval setting changes
Audit events are now created if changes are made to the merge request approval settings
in a project. You can now see if a change is made to the following policies:
- Requiring user password for approvals.
- Allowing modifying merge request approvals in a merge request.
- Needing to get new approvals when a new commit is added to a merge request.
You can now be confident that once you configure approval settings, you can quickly see
if they are changed. This is a great way to show auditors that controls were put in place
and have not been removed or modified.
Thanks to Adrien Gooris from Michelin for this contribution!
GPG key displayed on a user’s profile page
In previous versions of GitLab, there was no simple way to view a user’s GPG key. We’ve
added a button on profile pages that allows you to see a user’s GPG key with one click.
Show DORA API-based Deployment Frequency metric for Premium customers
This change enables the DORA API-based Deployment Frequency metric in group-level Value Stream Analytics for Premium customers. This can help you understand how often you are delivering increased value to your users. Also, higher deployment frequency means you are able to get feedback and iterate more quickly in delivering improvements and features.
Preview multimedia in the new Wiki editor
Including multimedia in a wiki page is a great way to effectively and efficiently communicate complex content. GitLab Flavored Markdown supports embedding video and audio content for playback. However, when you’re editing the page, the media is represented in code by the path to the file, and that can lead to confusion or uncertainty around whether you uploaded the right version of the file.
In GitLab 14.3, the new WYSIWYG Markdown editor in the Wiki renders and plays back existing video and audio content on the page right in the editor. Now you can be sure that the recording_final.mp3 or walkthrough.mp4 you attached is indeed the right asset without leaving the editor. Currently, this only applies to media already included in the page when it’s loaded into the editor. We will add support for inserting new video and audio content from the editor in an upcoming milestone.
Thanks to Lee Tickett for this helpful contribution!
GitLab Runner 14.3
We’re also releasing GitLab Runner 14.3 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.
What’s new:
Bug Fixes:
The list of all changes is in the GitLab Runner CHANGELOG.
Support merging CI/CD rules arrays with !reference
The YAML !reference tag introduced earlier this year helps you reuse and combine configuration. This is a very flexible way to combine frequently reused configuration with job-specific configuration in one or more jobs. However, using it with the rules keyword was not supported yet. In 14.3, we’ve added !reference support to the rules keyword, so you can now mix and match rules more easily, including with configuration from different files. You can use the CI/CD pipeline editor to view the merged configuration.
Search PyPI.org for packages not found in GitLab
You can use the GitLab Package Registry as a private PyPI index alongside your source code and pipelines. It’s common for teams to rely on a combination of private and public indexes. PyPI supports this by offering an -index and extra-index-url arguments that allow you to specify multiple indexes to download from. When installing a package pip will download the best match it can find, between all available indexes, not in priority order. For example, the latest version of a package will be chosen regardless of any priorities between indexes, simply because it’s the latest version. This presents a security concern for some organizations as it can make you vulnerable to dependency confusion attacks. For example, a developer may install a package thinking it was being sourced from a private GitLab project, but it is actually downloaded from the public repository instead.
You can use the GitLab Package Registry as a private PyPI index alongside your source code and pipelines. Moving forward, when you attempt to install a PyPI package from your GitLab project and the package isn’t found, the request is forwarded to PyPI.org. In other words, if the package name exists in your private registry, it’s excluded from the lookup from the public repository. This is done so that an attacker can’t inject code by uploading a package to PyPI with the same name and higher version.
This new feature is auto-enabled for GitLab.com and can be turned off by self-managed customers by using their Continuous Integration and Deployment Admin Area settings. This feature is currently limited to Premium customers, but GitLab-#337862 will move the feature to Core.
Remove deploy freeze period via the UI
To prevent unintentional deployments of your CI/CD jobs, you can set deploy freeze periods. Up until recently, it was possible to remove a deploy freeze period only by using the API. This release improves the ease of use by allowing you to remove a deploy freeze period directly from the GitLab interface.
This feature is a community contribution. Thank you @jayaddison for adding this useful feature to GitLab!
API endpoint to retrieve on-call user
Identifying who is on-call should be quick and easy, especially if there’s an active incident. This release adds an API call that returns the on-call users for each Escalation Policy of a project. Responders can use their preferred workflow, the GitLab UI or API, to find out who is on call.
GitLab Environment Toolkit (GET) 1.2 now available
The GitLab Environment Toolkit, a tool to deploy and operate production GitLab instances based on our Reference Architectures, has now reached version 1.2.
Highlights of 1.2 include support for AWS RDS, Elasticache, Geo on cloud native hybrid deployments, as well as all settings in Omnibus and Helm. To learn more about GET, the complete list of all changes, as well as upcoming breaking changes, please read the release notes.
Omnibus improvements
- GitLab 14.3 bundles Mattermost 5.38, an open source Slack-alternative. The newest release comes with many features and fixes, including a database migration that may take several minutes to complete. Refer to the Mattermost blog post for more details.
Static Analysis analyzer updates
GitLab Static Analysis is comprised of a set of many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. Below are the analyzer updates released during 14.3. These updates bring additional coverage, bug fixes, and improvements.
- Brakeman updated to version 5.1.1 - MR, Changelog
- Eslint updated to version 7.30.0 - MR, Changelog
- PMD Apex updated to version 3.38.0 - MR, Changelog
- Spotbugs updated to version 2.28.6 - MR, Changelog
- Semgrep updated to version 0.65.0 - MR, Changelog
- Performance improvements, ignore minified files, improved error messaging
If you are including the GitLab managed vendored SAST template (SAST.gitlab-ci.yml) you do not need to do anything to receive these updates. However, if you override or customize your own CI template, you will need to update your CI configurations. If you want to remain on a specific version of any analyzer, you can now pin to a minor version of an analyzer. Pinning to a previous version will prevent you from receiving automatic analyzer updates and require you to manually bump your analyzer version in your CI template.
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