AI生成摘要

Today we are releasing versions 16.6.1, 16.5.3, 16.4.3 for GitLab Community Edition (CE) and Enterprise Edition (EE). These versions contain important security fixes, and we strongly recommend that all GitLab installations be upgraded to one of these versions immediately. GitLab.com is already running the patched version. GitLab releases patches for vulnerabilities in dedicated security releases. There are two types of security releases: a monthly, scheduled security release, released a week after the feature release (which deploys on the 3rd Thursday of each month), and ad-hoc security releases for critical vulnerabilities. For more information, you can visit our security FAQ. You can see all of our regular and security release blog posts here. In addition, the issues detailing each vulnerability are made public on our issue tracker 30 days after the release in which they were patched. We are dedicated to ensuring all aspects of GitLab that are exposed to customers or that host customer data are held to the highest security standards. As part of maintaining good security hygiene, it is highly recommended that all customers upgrade to the latest security release for their supported version. You can read more best practices in securing your GitLab instance in our blog post. Recommended Action We strongly recommend that all installations running a version affected by the issues described below are upgraded to the latest version as soon as possible. When no specific deployment type (omnibus, source code, helm chart, etc.) of a product is mentioned, this means all types are affected. Table of fixes Title Severity XSS and ReDoS in Markdown via Banzai pipeline of Jira High Members with admin_group_member custom permission can add members with higher role High Release Description visible in public projects despite release set as project members only through atom response Medium Manipulate the repository content in the UI (CVE-2023-3401 bypass) Medium External user can abuse policy bot to gain access to internal projects Medium Client-side DOS via Mermaid Flowchart Medium Developers can update pipeline schedules to use protected branches even if they don't have permission to merge Medium Users can install Composer packages from public projects even when Package registry is turned off Medium Unauthorized member can gain Allowed to push and merge access and affect integrity of protected branches Low Guest users can react (emojis) on confidential work items which they cant see in a project Low XSS and ReDoS in Markdown via Banzai pipeline of Jira Improper neutralization of input in Jira integration configuration in GitLab CE/EE, affecting all versions from 15.10 prior to 16.6.1, 16.5 prior to 16.5.3, and 16.4 prior to 16.4.3 allowed attacker to execute javascript in victim's browser. This is a high severity issue (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N, 8.7). It is now mitigated in the latest release and is assigned CVE-2023-6033. Thanks yvvdwf for reporting this vulnerability through our HackerOne bug bounty program. Members with admin_group_member custom permission can add members with higher role An issue has been discovered in GitLab EE affecting all versions starting from 16.5 before 16.5.3, all versions starting from 16.6 before 16.6.1. When a user is assigned a custom role with admin_group_member` enabled, they may be able to add a member with a higher static role than themselves to the group which may lead to privilege escalation. This is a high severity issue (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, 8.1). It is now mitigated in the latest release and is assigned CVE-2023-6396. This vulnerability was discovered internally by GitLab team member jarka. Release Description visible in public projects despite release set as project members only through atom response An issue has been discovered in GitLab affecting all versions starting from 11.3 before 16.4.3, all versions starting from 16.5 before 16.5.3, all versions starting from 16.6 before 16.6.1. It was possible for unauthorized users to view a public projects' release descriptions via an atom endpoint when release access on the public was set to only project members This is a medium severity issue (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, 5.3). It is now mitigated in the latest release and is assigned CVE-2023-3949. Thanks ashish_r_padelkar for reporting this vulnerability through our HackerOne bug bounty program. Manipulate the repository content in the UI (CVE-2023-3401 bypass) An issue has been discovered in GitLab affecting all versions before 16.4.3, all versions starting from 16.5 before 16.5.3, all versions starting from 16.6 before 16.6.1. Under certain circumstances, a malicious actor bypass prohibited branch checks using a specially crafted branch name to manipulate repository content in the UI. This is a medium severity issue (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N, 4.8). It is now mitigated in the latest release and is assigned CVE-2023-5226. Thanks shells3c for reporting this vulnerability through our HackerOne bug bounty program. External user can abuse policy bot to gain access to internal projects An issue has been discovered in GitLab EE affecting all versions starting from 16.2 before 16.4.3, all versions starting from 16.5 before 16.5.3, all versions starting from 16.6 before 16.6.1. It was possible for an attacker to abuse the policy bot to gain access to internal projects. This is a medium severity issue (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N, 4.4). It is now mitigated in the latest release and is assigned CVE-2023-5995. Thanks joaxcar for reporting this vulnerability through our HackerOne bug bounty program. Client-side DOS via Mermaid Flowchart An issue has been discovered in GitLab EE affecting all versions starting from 10.5 before 16.4.3, all versions starting from 16.5 before 16.5.3, all versions starting from 16.6 before 16.6.1. It was possible for an attacker to cause a client-side denial of service using malicious crafted mermaid diagram input. This is a medium severity issue (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L, 4.3). It is now mitigated in the latest release and is assigned CVE-2023-4912. Thanks toukakirishima for reporting this vulnerability through our HackerOne bug bounty program. Developers can update pipeline schedules to use protected branches even if they don't have permission to merge An issue has been discovered in GitLab affecting all versions starting from 9.2 before 16.4.3, all versions starting from 16.5 before 16.5.3, all versions starting from 16.6 before 16.6.1. It was possible for a user with the Developer role to update a pipeline schedule from an unprotected branch to a protected branch. This is a medium severity issue (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, 4.3). It is now mitigated in the latest release and is assigned CVE-2023-4317. Thanks js_noob for reporting this vulnerability through our HackerOne bug bounty program. Users can install Composer packages from public projects even when Package registry is turned off An issue has been discovered in GitLab affecting all versions starting from 13.2 before 16.4.3, all versions starting from 16.5 before 16.5.3, all versions starting from 16.6 before 16.6.1. It was possible for users to access composer packages on public projects that have package registry disabled in the project settings. This is a medium severity issue (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, 4.3). It is now mitigated in the latest release and is assigned CVE-2023-3964. Thanks js_noob for reporting this vulnerability through our HackerOne bug bounty program. Unauthorized member can gain Allowed to push and merge access and affect integrity of protected branches An issue has been discovered in GitLab EE affecting all versions starting from 8.13 before 16.4.3, all versions starting from 16.5 before 16.5.3, all versions starting from 16.6 before 16.6.1. It was possible for an attacker to abuse the Allowed to merge permission as a guest user, when granted the permission through a group. This is a low severity issue (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N, 3.1). It is now mitigated in the latest release and is assigned CVE-2023-4658. Thanks theluci for reporting this vulnerability through our HackerOne bug bounty program. Guest users can react (emojis) on confidential work items which they cant see in a project An issue has been discovered in GitLab affecting all versions starting from 12.1 before 16.4.3, all versions starting from 16.5 before 16.5.3, all versions starting from 16.6 before 16.6.1. It was possible for a Guest user to add an emoji on confidential work items. This is a low severity issue (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N, 3.1). It is now mitigated in the latest release and is assigned CVE-2023-3443. Thanks ashish_r_padelkar for reporting this vulnerability through our HackerOne bug bounty program. Mattermost Security Update Mattermost has been updated to the latest patch release to mitigate several security issues. Update to PG 14.9 and 13.12 PostgreSQL has been updated to 14.9 and 13.12 to mitigate CVE-2023-39417. Update pcre2 to 10.42 pcre2 has been updated to version 10.42 to mitigate CVE-2022-41409. Non Security Patches 16.6.1 Install Gitaly dependencies for project archiving (16.6 backport) Fix intermittent 404 errors loading GitLab Pages Prefer custom sort order with search in users API Backport "Fix group page erroring because of nil user" to 16-6-stable-ee Skip encrypted settings logic for Redis when used by Mailroom Allow + char in abuse detection for global search Backport "Move unlock pipeline cron scheduler out of ee" to 16.6 Fix bug with pages_deployments files not being deleted on disk Backport - Truncate verification failure message to 255 Backport "Revert "Merge branch 'sc1-release-goredis' into 'master'"" 16.5.3 Backport 10871d71b171db38701bfefe15883b05c234ca6d to 16-5-stable Geo: Reduce batch size of verification state backfill 16.4.3 Backport 10871d71b171db38701bfefe15883b05c234ca6d to 16-4-stable Backport to 16.4 the fix for test failure due to "not-existing.com" being registered Bump asdf-bootstrapped-verify version on 16.4 Fix bulk batch export of badges and uploads [16.4] ci: Fix broken master by not reading GITLAB_ENV Fix assign security check permission checks For 16.4: Fix Geo verification state backfill job can exceed batch size Geo: Reduce batch size of verification state backfill Updating To update GitLab, see the Update page. To update Gitlab Runner, see the Updating the Runner page. Receive Security Release Notifications To receive security release blog notifications delivered to your inbox, visit our contact us page. To receive release notifications via RSS, subscribe to our security release RSS feed or our RSS feed for all releases.

本文以一个场景为例，展示了如何使用亚马逊云科技的 Serverless 服务，整合 Git 平台和国内办公 APP，完成审批流的功能。

Today, we are excited to announce the release of GitLab 16.6 with GitLab Duo Chat Available in Beta, MR approvals as a compliance policy, improved forking, improved UI for CI/CD variable management, and much more! These are just a few highlights from the 25+ improvements in this release. Read on to check out all of the great updates below. To the wider GitLab community, thank you for the 137 contributions you provided to GitLab 16.6! At GitLab, everyone can contribute and we couldn't have done it without you! To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 16.7 release kickoff video. MVP This month's Most Valuable Person (MVP) is awarded to Joe Snyder Joe Snyder was awarded GitLab’s 16.6 MVP for consistent contributions across GitLab, including recent merge requests to allow admins to filter runners by version. Joe was nominated by Miguel Rincon, Staff Frontend Engineer at GitLab. Miguel recognized Joe’s efforts through several required rewrites due to GitLab’s evolving architecture and commented on Joe’s “thoughtful consideration of performance and usability.” Pedro Pombeiro, Sr. Backend Engineer at GitLab, added that “Joe Snyder drove this change over the finish line after taking over from a former colleague, requiring learning all the context around the problem. He also proved very responsive and patient with our feedback in successive reviews.” “Joe has been a pleasure to work with,” said Terri Chu, Staff Backend Engineer at GitLab. Terri highlighted Joe’s ongoing work on emails_enabled changes over the last (and previous) milestone. Joe Snyder is a Senior R&D Engineer at Kitware and has been contributing to GitLab since 2021. Our many thanks to Joe for continuing to improve GitLab! 16.6 Key improvements released in GitLab 16.6 GitLab Duo Chat available in Beta GitLab Duo Chat available in Beta stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate Everyone involved in the software development process can spend a significant amount of time familiarizing themselves with code, epics, issues, and lengthy discussion threads. You can often find yourself slowed down by routine tasks like writing summaries, documentation, tests, or even code. Having an expert at your side that can answer DevSecOps questions without judgment and address follow-ups could help you accelerate the software development process. GitLab Duo Chat aims to actively address these pain points and accelerate your workflows. Its capabilities include: Explain or summarize issues, epics, and code. Answer specific questions about these artifacts like “Collect all the arguments raised in comments regarding the solution proposed in this issue.” Generate code or content based the information in these artifacts. For instance, “Can you write documentation for this code?” Or simply get you started from scratch like “Create a .gitlab-ci.yml configuration file for testing and building a Ruby on Rails application in a GitLab CI/CD pipeline.” Answer all your DevSecOps related question, whether you are beginner or an expert. For example, “How can I set up Dynamic Application Security Testing for a REST API?” Answer follow-up questions so you can iteratively work through all the above scenarios. GitLab Duo Chat is available on GitLab.com as a Beta feature. It is also integrated into our Web IDE and GitLab Workflow extension for VS Code as Experimental features. You can also help us mature these features by providing feedback about your experiences with Duo Chat, either within the product or via our feedback issue. Documentation Epic Automatic claims of enterprise users Automatic claims of enterprise users stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate When a GitLab.com user’s primary email address matches an existing verified domain, the user is automatically claimed as an enterprise user. This gives the group Owner more user management controls and visibility into the user’s account. After a user becomes an enterprise user, they can only change their primary email to an email their organization owns as per its verified domains. Documentation Epic Minimal forking - only include the default branch Minimal forking - only include the default branch stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate In previous versions of GitLab, when forking a repository, the fork always included all branches within the repository. Now you can create a fork with only the default branch, reducing complexity and storage space. Create minimal forks if you don’t need the changes that are currently being worked on in other branches. The default method of forking will not change and continue to include all branches within the repository. The new option shows which branch is the default, so that you are aware of exactly which branch will be included in the new fork. Documentation Issue Allow users to enforce MR approvals as a compliance policy Allow users to enforce MR approvals as a compliance policy stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate There is an increasing scrutiny on code changes that can potentially land in production applications and open businesses up to compliance risk and security vulnerability. With scan result policies, you can ensure unilateral changes cannot be made by enforcing two person approval on all merge requests. Scan results policies have a new option to target Any merge request which can be paired with defining role-based approvers to ensure each MR for the defined branches require approval by two (or more) users with a given role (Owner, Maintainer, or Developer). Available in SaaS in 16.6. Available for Self-managed behind the feature flag scan_result_any_merge_request and will be enabled by default in 16.7. Documentation Epic Switchboard portal for GitLab Dedicated is now generally available Switchboard portal for GitLab Dedicated is now generally available stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate Switchboard, a new self-service portal, is now available for customers and team members to onboard, configure and maintain their GitLab Dedicated instances. Using Switchboard, you can now make some configuration changes to your GitLab Dedicated instance. This functionality will expand in future releases. Documentation Issue CI/CD components Beta release CI/CD components Beta release stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate In GitLab 16.1, we announced the release of an exciting experimental feature called CI/CD components. The component is a pipeline building block that can be listed in the upcoming CI/CD catalog. Today we are excited to announce the Beta availability of CI/CD components. With this release, we have also improved the components folder structure from the initial experimental version. If you are already testing the experimental version of CI/CD components, it’s essential to migrate to the new folder structure. You can see some examples here. The old folder structure is deprecated and we plan to remove it within the next couple of releases. If you try out CI/CD components, you are also welcome to try the new CI/CD catalog, currently available as an experimental feature. You can search the Global CI/CD catalog for components that others have created and published for public use. Additionally, if you create your own components, you can choose to publish them in the catalog too! Documentation Issue Improved UI for CI/CD variable management Improved UI for CI/CD variable management stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate CI/CD variables are a fundamental part of GitLab CI/CD, and we felt that we could offer a better experience for working with variables from the settings UI. So in this release we’ve updated the UI to use a new drawer that improves the flow of adding and editing CI/CD variables. For example, the masking validation used to only happen when you tried to save the CI/CD variable, and if it failed you’d have to restart from scratch. But now with the new drawer, you get real time validation so you can adjust on the fly without needed to redo anything! Your feedback for this change is always valued and appreciated. Documentation Issue Runner Fleet Dashboard - Starter metrics (Beta) Runner Fleet Dashboard - Starter metrics (Beta) stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate Operators of self-managed runner fleets need observability and the ability to quickly answer critical questions about their runner fleet infrastructure at a glance. Now, with the Runner Fleet Dashboard - Admin View (Beta), you have actionable insights to help you quickly answer critical fleet management and developer experience questions, starting with instance runners. These include answers to questions like which runners have errors, the performance of the runner queues for CI job execution, and which runners are most actively used. Ultimate customers can enable this feature independently, but are encouraged to participate in the early adopter’s program. Documentation Issue 16.6 Other improvements in GitLab 16.6 Comprehensive list of items that failed to be imported Comprehensive list of items that failed to be imported stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate Previously, when migrating GitLab projects and groups by direct transfer had completed and some items (such as a merge requests or issues) were not successfully imported, you could select a Details button on the page listing imported groups and projects and see related errors there. However, a list of errors is not helpful to understand how many items in total, and which items in particular, were not imported. Having this information is crucial to understanding the results of the import process. In this release, we replaced the Details button with a See failures link. Selecting the See failures link takes you to a new page listing all items that failed to import for a given group or project. For each item that wasn’t imported, you can see: The type of the item. For example, merge request or issue. What kind of error occurred. The correlation ID, which is useful for debugging purposes. The URL of the item on the source instance, if available (items with iid). The title of the item on the source instance, if available. For example, the merge request title or the issue title. Documentation Issue GitLab Runner 16.6 GitLab Runner 16.6 stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate We’re also releasing GitLab Runner 16.6 today! GitLab Runner is the lightweight, highly-scalable agent that runs your CI/CD 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: GitLab Runner Fleeting plugin for GCP Compute Engine - Beta Implement graceful shutdown for Docker executor Dynamically create PVC volumes with storage classes for Kubernetes Override the container entrypoint through image.entrypoint in the Kubernetes executor Bug Fixes: Pods keep restarting with a Liveness probe failed error after upgrade to GitLab Runner 16.5.0 Debug terminal - variable contains content of file instead of file path Job execution pods in Kubernetes does not handle signals Services in GitLab Runner Docker executor using Podman do not start The list of all changes is in the GitLab Runner CHANGELOG. Documentation Prevent duplicate NuGet packages Prevent duplicate NuGet packages stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate You can use the GitLab Package Registry to publish and download your project’s NuGet packages. By default, you can publish the same package name and version multiple times. However, you might want to prevent duplicate uploads, especially for releases. In this release, GitLab has expanded the group setting for the Package Registry so you can allow or deny duplicate package uploads. You can adjust this setting with the GitLab API, or from the UI. Documentation Issue Connect to Kubernetes clusters with the GitLab CLI Connect to Kubernetes clusters with the GitLab CLI stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate From GitLab version 16.4, you can connect to a Kubernetes cluster from a local terminal using the agent for Kubernetes and a personal access token. In the initial version, setting up the local cluster configuration required several commands and a long lived access token. In the past month, we worked to streamline and improve the security of the set up process by extending the GitLab CLI. The GitLab CLI can now list the agent connections available from a GitLab project checkout directory or the specified project. You can set up the connection through a selected agent with a dedicated command. When kubectl or any other tool needs to authenticate with the cluster, the GitLab CLI generates a temporary, restricted token for the signed-in user. Documentation Epic Added support for SBT projects using Java 21 Added support for SBT projects using Java 21 stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate Dependency Scanning and License Scanning now support SBT projects using Java 21. Documentation Issue DAST analyzer updates DAST analyzer updates stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate During the 16.6 release milestone, we enabled the following active checks for browser-based DAST by default: Check 94.1 replaces ZAP check 90019 and identifies server-side code injection (PHP). Check 94.2 replaces ZAP check 90019 and identifies server-side code injection (Ruby). Check 94.3 replaces ZAP check 90019 and identifies server-side code injection (Python). Check 943.1 replaces ZAP check 40033 and identifies improper neutralization of special elements in data query logic. Check 74.1 replaces ZAP check 90017 and identifies XSLT injection. Documentation Issue Allow compliance teams to prevent pushing and force pushing into protected branches Allow compliance teams to prevent pushing and force pushing into protected branches stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate One of several new settings being added to scan result policies to aide in compliance enforcement of security policies, this control will limit the ability to leverage project-level settings to circumvent policies. For each existing or new scan result policy, you can enable Prevent pushing and force pushing to take effect for the branches defined within the policy to prevent users from circumventing the merge request flow to push changes directly to a branch. Available in SaaS in 16.6. Available for Self-managed behind the feature flag scan_result_policies_block_force_push and will be enabled by default in 16.7. Documentation Epic Group-level audit event streaming to AWS S3 Group-level audit event streaming to AWS S3 stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate Building on our integrations with external logging or data aggregation tools, you can now select AWS S3 as a destination for audit event streams for top-level groups. This feature provides relevant information for an easier and more trouble-free integration. Previously, you had to use custom HTTP headers to try to build a request that AWS S3 would accept. This method was prone to errors and could be difficult to troubleshoot. Documentation Issue Service accounts have optional expiry dates Service accounts have optional expiry dates stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate GitLab administrators and group Owners can choose if they want to enforce an expiry date for service accounts. Previously, service account tokens had to expire within a year, in line with personal, project, and group access token expiration limits. This allows administrators and group Owners to choose the balance between security and ease of use that best aligns with their goals. Documentation Issue Consistent navigation experience for all users Consistent navigation experience for all users stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate The 16.0 release introduced a new navigation experience, which became the default for all users on June 2, 2023. In subsequent milestones, many improvements were made based on a wealth of user feedback. The ability to fall back to the old navigation has now been removed. More exciting changes are planned for the navigation, but for now, all users have a consistent navigation experience. As a recap, with the new GitLab navigation, you can: Pin menu items to save your most-used project or group items at the top Hide and “peek” the navigation to expose a wider screen Easily search for menu items by using keyboard shortcuts Continue to use all the themes you had with the previous navigation Use better-organized sections that align with a DevOps workflow Documentation Issue macOS 14 (Sonoma) and Xcode 15 image support macOS 14 (Sonoma) and Xcode 15 image support stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate Teams can now seamlessly create, test, and deploy applications for the Apple ecosystem on macOS 14 and Xcode 15. SaaS runners on macOS allow you to increase your development teams’ velocity in building and deploying applications that require macOS in a secure, on-demand GitLab Runner build environment integrated with GitLab CI/CD. Try it out today by using macos-14-xcode-15 as the image in your .gitlab-ci.yml file. Documentation Issue Upload packages to the Maven repository with basic HTTP authentication Upload packages to the Maven repository with basic HTTP authentication stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate The GitLab Package Registry now supports uploading Maven packages with basic HTTP authentication. Previously, you could use basic HTTP authentication only to download Maven packages. This inconsistency made it difficult for developers to configure and maintain authentication for their project. Publishing artifacts with sbt is not supported, but issue 408479 proposes to add this feature. Documentation Issue Real-time Kubernetes status updates in the GitLab UI Real-time Kubernetes status updates in the GitLab UI stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate In GitLab 16.6, you can use the cluster UI integration on your environment page to determine the status of currently running applications without leaving GitLab. Previously, the status was updated by a one-time request when the UI loaded, which made tracking deployment progress unwieldy. The current version of GitLab upgrades the underlying connection to use the Kubernetes watch API for the Flux reconciliation and Pod statuses, and provides near real-time updates of the cluster state in the GitLab UI. Documentation Issue Container Scanning: Exclude findings which won’t be fixed Container Scanning: Exclude findings which won’t be fixed stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate Container scanning results may include findings which the vendor has evaluated and decided to not fix. To allow you to focus on actionable findings, you can now exclude such findings. For configuration options please refer to the GitLab documentation. Documentation Issue Include CVSS Vectors in the vulnerability report export Include CVSS Vectors in the vulnerability report export stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate When you export information from the vulnerability report, the CVSS Vector information is now included. This additional data helps you analyze and triage vulnerabilities outside GitLab. Documentation Issue Changes to the vulnerability report’s Tool filter Changes to the vulnerability report’s Tool filter stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate Previously, the vulnerability report allowed you to filter by a static list of GitLab-supported tool types, followed by a dynamic list of custom scanners. With this release, you can now select tool type grouped by analyzer. Documentation Epic Improved handling of unresponsive external status checks Improved handling of unresponsive external status checks stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate Previously, external status checks on MRs continued to poll the external URL until they received either a successful or failed response. This could result in some status checks seeming to hang in an unresponsive state. Now, a 2 minute timeout has been incorporated so that you can manually retry the status check after 2 minutes if you are not getting any response from the external system. Documentation Issue GitLab Silent Mode GitLab Silent Mode stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate When GitLab Silent Mode is enabled, it blocks all major outbound traffic such as notification emails, integrations, webhooks, and mirroring from a GitLab instance. This allows you to perform testing against a GitLab site without generating traffic towards users and other integrations. You can use Silent Mode to test a restored backup or a promoted Geo DR site without impacting your primary GitLab site or your end users. Documentation Epic Hide archived projects in search results by default Hide archived projects in search results by default stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate Previously, users saw many archived projects in their project search results. This was problematic, especially when archived projects took up many of the top results. We now filter out archived projects by default, and users can select Include archived to see all projects. Documentation Epic Private group names are hidden from unauthorized users Private group names are hidden from unauthorized users stage-badge SaaS Free Premium Ultimate Self-Managed Free Premium Ultimate Previously, the names of private groups were visible to all users when accessing the Groups tab of a project’s or group’s members page. To enhance security, we are now masking private groups’ name and source from users who are not members of the shared group, shared project, or invited group. Instead, this information will be displayed as Private. Documentation Issue Bug fixes, performance improvements, and usability improvements Bug fixes, performance improvements, and usability improvements At GitLab, we’re dedicated to providing the best possible experience for our users. With every release, we work tirelessly to fix bugs, improve performance, and enhance usability. Whether you’re one of the over 1 million users on GitLab.com or using our platform elsewhere, we’re committed to making sure your time with us is smooth and seamless. Click the links below to see all the bug fixes, performance enhancements, and usability improvements we’ve delivered in 16.6. Bug fixes Performance improvements Usability improvements Deprecations Deprecations New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed. The GitHub importer Rake task Proxy-based DAST deprecated GraphQL: deprecate support for `canDestroy` and `canDelete` Breaking change to the Maven repository group permissions File type variable expansion fixed in downstream pipelines Legacy Geo Prometheus metrics Container Registry support for the Swift and OSS storage drivers Removals and breaking changes Removals and breaking changes The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed. Job token allowlist covers public and internal projects Other notable changes Other notable changes GitLab continues to expand the Registration Features Program GitLab continues to expand the Registration Features Program Building on what we started in 14.1 and beyond, in 16.5 and 16.6 GitLab has introduced an additional 10 features to the Registration Features Program: Group wikis - GitLab 16.5 and later Issue analytics - GitLab 16.5 and later Custom Text in Emails - GitLab 16.5 and later Contribution analytics - GitLab 16.5 and later Group file templates - GitLab 16.6 and later Group webhooks - GitLab 16.6 and later Service Level Agreement countdown timer - GitLab 16.6 and later Lock project membership to group - GitLab 16.6 and later Users and permissions report - GitLab 16.6 and later Advanced search - GitLab 16.6 and later If you are interested in participating as a free self-managed user running GitLab Enterprise Edition, you can read about how to turn on Service Ping here.

Today we are releasing versions 16.5.2 for GitLab Community Edition and Enterprise Edition. These versions resolve a number of regressions and bugs. GitLab Community Edition and Enterprise Edition 16.5.2 Backport to 16.5: Geo: Bring back legacy project Prometheus metrics Backport artifacts page breadcrumb fixes Fix broken issue rendering when initial ID is null Backport - Create group wiki repo if absent when verifying on primary backport to 16.5: Fix Geo verification state backfill job can exceed batch size Fix assign security check permission checks Update postgres_exporter from 0.14.0 to 0.15.0 (16.5 backport) Important notes on upgrading This version does not include any new migrations, and for multi-node deployments, should not require any downtime. Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-reconfigure file, which is only used for updates. Updating To update, check out our update page. GitLab subscriptions Access to GitLab Premium and Ultimate features is granted by a paid subscription. Alternatively, sign up for GitLab.com to use GitLab's own infrastructure.

GitLab Duo Chat, the newest feature in the GitLab Duo suite of AI-assisted capabilities, helps teams write and understand code faster, get up to speed on the status of projects, and quickly learn GitLab. Chat will be available in Beta starting November 16. Chat also will be included in our Web IDE and GitLab Workflow extension for VS Code as an experimental release. Get code explanations, generate tests, and create code right where your development work happens; no need for context switching. We launched the GitLab Duo suite earlier this year to bolster software development teams' workflow, helping you deliver more secure software at an unprecedented pace and create more value for your customers. GitLab is the only platform that brings AI-powered planning tools, code creation, security scanning, and vulnerability remediation all into a single developer-friendly experience. Chat will serve as the foundational technology driving our AI-powered GitLab Duo features, such as Vulnerability Summary and Root Cause Analysis. This will enable you to pose in-context follow-up questions for a more thorough investigation. Try GitLab Duo Chat with a free Ultimate trial. In our Global DevSecOps Report: The State of AI in Software Development, 83% of respondents said that implementing AI in their software development processes is essential to avoid falling behind, and they ranked chatbots among their top three AI use cases. Chat, which will be released for Ultimate tier customers as part of GitLab 16.6, is the perfect feature to help you maintain your competitive advantage. Here's why. Designed to support everyone across the software development process From coding assistance to productivity tips, Chat provides real-time support for technical and non-technical users across the entire software development lifecycle. Inspiration on demand: Need help determining the next best step in your workflow? Chat is ever-ready to ignite your ideation process. Elevate productivity: Chat shoulders the burden of routine tasks so you can channel your energy into delivering value to your customers. Guidance at every step: Whether you're a GitLab expert or a newcomer, Chat is your go-to coach, helping you become an expert in any process or feature. Sometimes, there isn't enough time in the day, and even though you want to focus on important tasks, there are many little things you need to do. Code assistance: Chat can assist in decoding the mysteries of unfamiliar code. It can explain, propose tests, or simplify the code. You can also use Chat to write code from scratch interactively. Issue and epic management: Summarize an issue in seconds, turn comments into an issue description, or distill specific information from large epics easily. You can ask any question about the content of an epic or an issue. Plan work with issues and epics faster with the help of Chat. Onboarding and learning made simple: Whether you are onboarding to GitLab or you are already an expert learning how to use GitLab is streamlined with Chat. How your data stays your data Chat does not use your proprietary code or inputs to Chat as training data. This privacy-first approach includes both the prompt and the output of Chat. GitLab Duo uses the right large language models (LLMs) for each use case. For instance, Anthropic Claude-2 and Vertex AI Codey with text embedding-gecko LLMs power Chat. Our publicly available documentation describes all AI models GitLab Duo uses and how it uses your data. The road ahead for GitLab Duo As we continue to innovate and improve GitLab Duo, we're excited to share that our Code Suggestions capability will transition from Beta to general availability later this year. We look forward to seeing the transformative impact GitLab Duo will have on your software development efforts. Learn more about GitLab Duo Chat in our documentation and share your feedback and ideas. Try GitLab Duo Chat with a free Ultimate trial. Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.

Continuous integration and continuous deployment (CI/CD) are a crucial part of the product development workflow. Companies depend on CI/CD to get new software features, bug fixes, and improvements out the door quickly. At GitLab, runners are at the core of CI/CD and are needed to build, test, and deploy code. GitLab Runner is the open source project that is used to run CI/CD jobs and send the results back to GitLab. However, since GitLab's early years, GitLab Runner has been code-centric with limited UI capabilities. We recently embarked on a journey to change that – follow along to see how we gathered user input and made desired improvements to the visibility and metrics of the GitLab Runner Fleet dashboard. Managing runners As GitLab scaled as a company, so did the number of GitLab users with complex and evolving use cases. In the past five years, we have seen a radical increase in the need for a best-in-class experience when managing a large number of self-managed runners. This need has led us to put more time and focus into improving how GitLab manages runners and how it supports users in making decisions quickly and effectively. To that end, we’ve been making incremental changes to the runner fleet management experience, including improving the general usability of admin and group runner pages, providing more data around runners such as jobs run and status checks, and improving the runner creation process so it’s more secure and easier to follow. By doing this, we built a better underlying system so we could add new features easily. However, runner admins and platform engineers shared this recurring problem with us: It is difficult to get an at-a-glance view of my fleet of runners, including how they are performing (how fast they pick up jobs, which ones are running the most jobs, etc.) and what issues (if any) are present that need to be fixed. In addition to this problem, the GitLab Runner Fleet team was also running into issues with the performance of runner pages and with scalability when trying to add new features. This was a perfect opportunity to learn more about the problem users were facing and to innovate to extend our runner offering. Gathering insights and exploring proposals To fully understand the problem at hand and help make the requirements more clear, we carried out problem validation research. We held moderated in-depth interviews and sifted through much of our existing data from previous interviews. As we gained confidence in our understanding of the problem, we created a first iteration of the design to be tested with users through moderated usability testing, which would determine whether the solution really did solve the problem. This first design proposal focused on: a general overview of the fleet, broken down by types (instance, group, project runners) and status visibility into runner system failures a general concept of runner load - how many jobs are running at once out of how many possible jobs the runner can run? how long it takes for runners to pick up jobs = a list of runner events (job failures, status changes, upgrades, etc.) Testing the usability of iteration We ran moderated usability testing sessions so we could measure user responses and satisfaction based on a set of consistent questions across multiple participants. We used a Figma prototype and had participants complete tasks that connected back to the problem we were solving. An advantage of running moderated sessions compared to unmoderated sessions is that we could tailor our follow-up questions as required once participants completed a task or provided an answer. After completing these sessions, we summarized the data we received into the following key insights to create the MVC (minimal viable change) of the runner fleet dashboard: Runner failures/errors are crucial to identify problems (voted the most important feature on the dashboard). Online and offline runners matter the most in terms of status breakdowns for a fleet. Visibility into busy runners (tied for second most important feature on the dashboard) helps users see individual runner load. Wait time to pick up a job was tied for the second most important feature on the dashboard and seeing this over time with more configuration options can help identify where to make optimizations in the fleet. There are many other features requested by participants that should be handled in follow-up iterations of the dashboard. See this epic for more information. Updating the designs Our next step was to update the designs to consider the research we ran. Responding to feedback 1) Wait times What we heard: “Right now, there is very little information available as to how soon a CI build might start. Oftentimes, users are left wondering why jobs won’t run.” “It's mostly reactive for us at this point anyway when, as you know, we get users reporting problems, we might want to go look at wait times here. And be able to dig down on those to see who's waiting…” What we did: Added an in-depth visualization of wait times for all instance runners in the fleet in the past three hours and included percentiles to give users a true representation of the wait times. By providing the data over this interval, we enable runner admins to quickly get a sense of how their runners are performing and if there are any issues with the fleet that would cause jobs to stay in pending state. 2) Runner loads What we heard: “I have three build servers that are shared amongst many projects and in order for me to ensure each build server is properly set up, it's important for me to track builds by server. So, if one particular server is having issues, I need to be able to focus on that server.” What we did: To start indicating some data on runner load, we’ve added a list of the top five busiest runners based on the number of running jobs they have at the moment, ranked from highest to lowest. This should help when analyzing concurrency settings and seeing if runners really need the capacity set for them. 3) Understanding of most recent failures What we heard: “We actually have a dashboard on Datadog that gives us error counts and errors coming from the runners themselves. But you know, without a dashboard, we have no visibility on anything inside of GitLab, like queue lengths or wait times or anything like that.” “Our setup is not perfect…some of the runners run on spot instances and can disappear, which means the background engine can die. You get this very strange error that the job failed because of something and we need to retry the job using a different runner.” What we did: Created a list of most recent failures in the last hour for instance runners. Not only can you quickly navigate to the job log and details, but you’re also given a short summary of the error so you get insight into it immediately and can get on your way to fix it. The full dashboard: What's next? This first iteration of the dashboard is not the end. We have many iterations planned to improve the dashboard over the next year. To first get feedback on how it works for users, we will run an Early Adopters Program for GitLab Ultimate self-managed users. We will work with teams to set up the feature on their instance and continuously ask for feedback once it is being used. This will also help us understand user satisfaction levels and help our team prioritize fixes and new features as we continue improving the experience. Do you want to provide feedback now? We would love to hear what you think! Please add your thoughts about the Fleet Dashboard to this feedback issue. To learn more about how we built this dashboard, watch this technical demo by Miguel Rincon, Pedro Pombeiro, and Vladimir Shushlin.

In today's dynamic landscape of software development, certain requirements have become paramount for delivering high-quality software rapidly. These requirements include the need for cloud compatibility, faster development cycles, improved collaboration, containerization, enhanced development experiences, and the integration of AI-driven capabilities for better efficiency and speed. Jenkins, a longstanding and respected continuous integration (CI) tool, has admirably played a role in many teams' software development for years. However, as more teams adopt DevOps/DevSecOps strategies for their software delivery, leveraging the integrated CI that is available in a DevSecOps platform like GitLab can provide benefits that Jenkins does not. Some organizations find themselves hesitating to migrate, not because they doubt the benefits of a top-tier CI/CD solution such as GitLab, but due to the complexities of their existing Jenkins implementations. It's understandable that such a transition can seem daunting. In this blog, you'll find several migration strategies to help transition from Jenkins to GitLab and make the process smoother and more manageable. Migrating to GitLab A recommended step-by-step Jenkins-to-GitLab CI migration 3 Jenkins-to-GitLab CI migration strategies Technical insights: How the migration works Strategic planning for a smooth transition Case study: A seamless transition for Lockheed Martin GitLab documentation and support Migrating to GitLab It's become evident that for organizations seeking a CI/CD solution that can seamlessly support their evolving demands, GitLab emerges as a powerful game-changer. Let's explore why transitioning to this advanced platform is transformative for Jenkins users. Why migrate to GitLab Before we delve into the migration approaches, let's take a moment to understand GitLab CI and what makes it a compelling choice for modern CI/CD needs. Try GitLab CI/CD today with a free trial of Ultimate. GitLab CI overview GitLab CI is an integral part of the GitLab AI-powered DevSecOps Platform, which offers a comprehensive and unified solution for DevSecOps and CI/CD. GitLab's design revolves around streamlining development workflows, fostering collaboration, enhancing security, and ensuring scalability. Key features of GitLab CI These are the key features of GitLab CI: Unified platform: GitLab CI is more than just a CI/CD tool; it's part of a broader ecosystem that includes source code management, project management, security features, analytics and more. This unified platform streamlines workflows and enhances collaboration among development teams. Containerization and orchestration: GitLab CI/CD is designed with containerization in mind, offering native support for Docker and Kubernetes. This enables seamless integration of container technologies into your CI/CD pipelines. Security by design: Security is a top priority, and GitLab CI incorporates features such as static code analysis and vulnerability scanning to help teams identify and address security issues early in the development process. GitOps principles: GitLab CI aligns with GitOps principles, emphasizing version-controlled, declarative configurations for infrastructure and application deployments. This approach enhances the reliability and repeatability of deployments. Get familiar with GitLab CI with this tutorial: With that understanding of GitLab CI's capabilities, let's explore the migration steps and strategies for Jenkins users looking to leverage the benefits of GitLab CI. A recommended step-by-step Jenkins-to-GitLab CI migration When considering a migration from Jenkins to GitLab CI, we strongly recommend following a well-structured, step-by-step approach to ensure a seamless transition. Here's our recommended process: Pipeline assessment: Start by conducting a comprehensive inventory of all your existing pipelines in Jenkins. This initial step will help you gain a clear understanding of the scope and complexity of the migration. Parallel migration: Begin the migration process by selecting individual pipelines and moving them to GitLab CI one at a time. Continue to maintain the use of Jenkins for your ongoing work during this transition to minimize disruptions. Code verification: We advise beginning with verification checks in CI. Run both the Jenkins and GitLab CI pipelines in parallel. This dual approach allows you to directly compare the two workflows and identify any issues in the new GitLab workflows. During this phase, keep the GitLab workflow as an optional choice while Jenkins remains required. Continuous validation: After running both pipelines in parallel for a full iteration, thoroughly evaluate the outcomes from each pipeline. This evaluation should consider various factors, including status codes, logs, and performance. GitLab CI transition: As you gain confidence in the reliability and effectiveness of GitLab CI through the parallel runs, make the transition to the GitLab CI workflow as the required standard while Jenkins continues to operate in the background. Jenkins phaseout: After a second iteration, when you are confident in the performance and stability of GitLab CI, you can begin to remove the Jenkins job from your code verification pipeline. This successful transition will enable you to retire Jenkins from this particular aspect of your CI/CD process. This recommended approach ensures that your migration is a gradual evolution, allowing you to identify and address any issues or discrepancies before fully committing to GitLab CI. Running Jenkins and GitLab CI pipelines in parallel provides valuable insights and ensures the effective streamlining of your CI/CD processes. Preparing for migration: Training and communication To ensure a smooth and successful migration from Jenkins to GitLab CI, follow these essential steps: Stakeholder communication: Start by announcing your migration plans and timelines to all relevant stakeholders. This includes DevOps teams, developers, and QA engineers. Transparency in communication is crucial to ensure that everyone understands the objectives and expectations of the migration. Knowledge-level training: Conduct knowledge-level training sessions for your teams to promote GitLab CI adoption. Cover topics such as using GitLab CI, understanding the YAML syntax, and how to create a basic pipeline. Provide team members with the knowledge and skills necessary to navigate the new GitLab CI environment effectively. Hands-on learning: Encourage hands-on learning by pairing up developers. Create opportunities for them to learn from each other's experiences throughout the migration process. By following these instructions for training and communication, you'll build a strong foundation for a successful migration, empowering your teams to adapt and thrive in the new environment. 3 Jenkins-to-GitLab CI migration strategies There are different strategies to consider. These three strategies offer flexibility, allowing organizations to choose the path that best aligns with their specific needs and resources. Let's explore these strategies in detail to help you make an informed decision about which one suits your organization best. Migration Strategy 1: Using GitLab CI for new projects The first migration strategy involves a gradual transition. While you maintain your existing Jenkins infrastructure for ongoing projects, you introduce GitLab CI for new projects. This approach allows you to harness the modern features of GitLab CI without disrupting your current work. Benefits of Migration Strategy 1 The benefits of this approach include the following: New projects can leverage GitLab CI's advanced features right from the start. This strategy minimizes the risk of disrupting existing workflows, as your existing Jenkins setup remains intact. Your team can gradually adapt to GitLab CI, building confidence and expertise without the pressure of an immediate full-scale migration. Challenges of Migration Strategy 1 The challenges of this approach include the following: Operating two CI/CD platforms simultaneously can introduce complexity, especially in terms of integration and team collaboration. Managing projects on different platforms may require careful coordination to ensure consistency in processes and security practices. This strategy offers a smooth and manageable transition by allowing you to harness GitLab CI's strengths for new projects, while your existing Jenkins infrastructure continues to support ongoing work. Migration Strategy 2: Migrating only strategic projects In this strategy, you identify specific projects within your organization that stand to benefit the most from the capabilities of GitLab CI. Instead of preparing for a wholesale migration, you start by focusing your efforts on migrating these strategically selected projects first. Benefits of Migration Strategy 2 The benefits of this approach include the following: By concentrating on key projects, you can realize significant improvements in those areas where GitLab CI aligns with specific needs. This approach reduces the complexity of migrating everything at once, minimizing the potential for disruptions. You can gradually build confidence with GitLab CI and its benefits before considering further migrations. Challenges of Migration Strategy 2 The challenges of this approach include the following: Even though you're not migrating all projects, the chosen projects' migration can still be intricate and require careful planning. Ensuring seamless collaboration between projects on different platforms may require additional attention. This strategy allows you to maximize the impact of GitLab CI by focusing on strategic areas, minimizing risk, and gradually gaining experience with the new tool. Migration Strategy 3: Migrating everything The third strategy is a comprehensive migration where you commit to moving all your CI/CD processes, projects, and workflows to GitLab CI. This approach aims for uniformity and simplification of CI/CD across all projects. This strategy can benefit from taking an iterative approach. Consider starting with new projects, followed by migrating strategic projects, and then leverage your growing knowledge and experience with GitLab CI to complete the migration of remaining projects. Benefits of Migration Strategy 3 The benefits of this approach include the following: Uniform CI/CD processes across all projects can streamline administration and maintenance, reducing complexity. You can take full advantage of GitLab CI's modern capabilities, from Infrastructure as Code to enhanced security features. As your projects grow, GitLab CI is designed to handle increased demands, ensuring long-term scalability. Challenges of Migration Strategy 3 The challenges of this approach include the following: A full-scale migration can be intricate, requiring meticulous planning and implementation. The transition may disrupt ongoing projects and require a significant time investment. Investment in training and potential tool migration expenses should be considered. Opt for this approach if uniformity and consolidation of CI/CD processes are a high priority, and you have the resources to execute a full migration. The migration strategy you select should align with your organization's specific needs and circumstances. In all cases, the ultimate goal is to enhance your development process with modern CI/CD tools like GitLab CI, which offers scalability, infrastructure automation, security, and collaboration features that align with today's development needs. Technical insights: How the migration works Moving your CI/CD workflows from Jenkins to GitLab CI is a transformative journey, and understanding how it works is vital for a successful transition. Understanding the configurations: Jenkinsfile vs. .gitlab-ci.yml The heart of your CI/CD pipeline lies in the configurations defined in your Jenkinsfile (for Jenkins) and .gitlab-ci.yml (for GitLab CI). While there are some similarities between these configuration files, there are notable differences as well. Similarities Both files define the stages, jobs, and steps of your CI/CD process. You specify the desired build, test, and deployment steps in both files. Environment variables and settings can be configured in either file. Differences Jenkinsfile uses Groovy for scripting, while .gitlab-ci.yml uses YAML. This change in language affects the way you write and structure your configurations. The process of defining pipelines is more intuitive in .gitlab-ci.yml, with a cleaner, more human-readable syntax. GitLab CI provides a wide range of built-in templates and predefined jobs, simplifying configuration and reducing the need for custom scripting. Manually converting the pipeline configuration Currently, migrating your existing Jenkins pipelines to GitLab CI is typically done manually. This means analyzing your Jenkinsfile and re-creating the equivalent configurations in .gitlab-ci.yml. While there are similarities in the concepts and structure, the differences in syntax and the specific capabilities of each platform require careful consideration during the migration. Strategic planning for a smooth transition Migrating from Jenkins to GitLab CI requires meticulous planning to ensure a seamless transition. It's crucial to assess the disparities between the two systems and evaluate their impact on your workflow, considering aspects like security, cost, time, and capacity. Once you've identified these differences and devised your migration strategy, break down the migration into key steps. These include setting up GitLab CI pipelines, securely transferring data from Jenkins to GitLab CI, and integrating GitLab CI into your existing tools and processes. Case study: A seamless transition for Lockheed Martin Let's look at a real-world case study to illustrate the effectiveness of the "Migrate Everything" strategy. Lockheed Martin, the world’s largest defense contractor, had been using Jenkins for several years. As their project portfolio expanded, they realized that their Jenkins implementation with a wide variety of DevOps tools was becoming increasingly complex to manage. They were also eager to adopt modern CI/CD capabilities that Jenkins struggled to provide. In collaboration with GitLab, Lockheed Martin decided to undertake a comprehensive migration to GitLab CI. Their goals included achieving consistency in their CI/CD processes, simplifying administration and maintenance, and taking full advantage of The GitLab Platform’s robust features. The comprehensive migration strategy proved to be a resounding success for Lockheed Martin. With GitLab CI, they not only streamlined their CI/CD processes but achieved remarkable results. They managed to run CI pipeline builds a staggering 80 times faster, retired thousands of Jenkins servers, and reduced the time spent on system maintenance by a staggering 90%. This monumental shift resulted in a significant increase in efficiency and productivity for Lockheed Martin. This case study showcases how a comprehensive migration strategy can be effective for organizations looking to leverage GitLab capabilities across all their projects. For more in-depth insights into Lockheed Martin's successful transition to GitLab and how it streamlined their software development processes, check out the detailed case study. GitLab documentation and support For those embarking on this migration journey, GitLab offers documentation to guide you through the process. You can find valuable resources in GitLab's official documentation. In addition to documentation, GitLab's Professional Services team is available to assist organizations in their migrations. They bring expertise and experience to ensure a smooth transition. Whether it's understanding the nuances of Jenkinsfile to .gitlab-ci.yml conversion or optimizing your CI/CD workflows, their support can be invaluable. Try GitLab CI/CD today with a free trial of Ultimate.

When you develop software that users rely on, effective communication about changes with each release is essential. By keeping users informed about new features and any modifications or removals, you ensure they maximize the software's benefits and avoid encountering unpleasant surprises during upgrades. Historically, creating release notes and maintaining a changelog has been a laborious task, requiring developers to monitor changes externally or release managers to sift through merge histories. With the GitLab Changelog API, you can use the rich history provided in our git repository to easily create release notes and maintain a changelog. In this post, we'll delve into automating releases with GitLab, covering the generation of release artifacts, release notes, and a comprehensive changelog detailing all user-centric software modifications. Releases in GitLab First, let's explore how releases work in GitLab. In GitLab, a release is a specific version of your code, identified by a git tag, that includes details about changes since the last release (and release notes) and any related artifacts built from that version of the code, such as Docker images, installation packages, and documentation. You can create and track releases in GitLab using the UI by calling our Release API or by defining a special release job inside a CI pipeline. In this tutorial, we'll use the release job in a CI/CD pipeline, which allows us to extend the automation we're using in our pipelines for testing, code scanning, etc. to also perform automated releases. To automate our releases, we first need to answer this question: Where are we going to get the information on changes made for our release notes and our changelog? The answer: Our git repository, which provides us with a rich history of development activity through commit messages and merge commit history. Let's see if we can leverage this rich history to automatically create our notes and changelogs. Introducing commit trailers Commit trailers are structured entries in your git commits, created by adding simple <HEADER>:<BODY> format messages to the end of your commit. The git CLI tool can then parse and extract these for use in other systems. An example you might have already used is git commit --sign-off to sign off on a commit. This is implemented by adding a Signed-off-by: <Your Name> trailer to the commit. We can add any arbitrary structured data here, which makes it a great place to store information that could be useful for our changelog. In fact, if we use a Changelog: <added/changed/removed> trailer in our commits, the GitLab Changelog API will parse these and use them to create a changelog for us automatically! Let's see this in action by making some changes to a real codebase and performing a release, and generating release notes and changelog entries. Our example project For the purposes of this blog, I'm using a simple Python web app repository. Let's pretend Version 1.0.0 of the application was just released and is the current version of the code. I've also created a 1.0.0 release in GitLab, which I did manually because we haven't created our automated release pipeline yet: Making our changes We're in rapid development mode, so we're going to be working on releasing Version 2.0.0 of our application today. As part of our 2.0.0 release, we're going to be adding a new feature to our app: A chatbot! And we're also going to be removing the quantum blockchain feature, because we only needed that for our first venture capital funding round. Also, we're going to be adding an automated release job to our CI/CD pipeline for our 2.0.0 release. First, let's remove unneeded features. I've created a merge request that contains the necessary removals. Importantly, we need to ensure we have a commit message that includes the Changelog: removed trailer. There's a few ways to do this, such as including it directly in a commit, or performing an interactive rebase and adding it using the CLI. But I think the easiest way in our situation is to leave it until the end and then use the Edit commit message button in GitLab to add the trailer to the merge commit like so: If you use this method, you can also change the merge commit title to something more succinct. I've changed the title of my merge commit to 'Remove Unused Features', as this is what will appear in the changelog entry. Next, let's add some new functionality for the 2.0.0 release. Again, all we need to do is open another merge request that includes our new features and then edit the merge commit to include the Changelog: added trailer and edit the commit title to be more succinct: Now we're pretty much ready to release 2.0.0. But we don't want to create our release manually this time. So before our release we're going to add some jobs to our .gitlab-ci.yml file that will perform the release for us automatically, and generate the respective release notes and changelog entries, when we tag our code with a new version like 2.0.0. Note: If you want to enforce changelog trailers, consider using something like Danger to perform automated checks for MR conventions. Building an automated release pipeline For our pipeline to work, we need to create a project access token that will allow us to call GitLab's API to generate changelog entries. Create a project access token with the API scope, and then store the token as a CI/CD variable called CI_API_TOKEN. We'll reference this variable to authenticate to the API. Next, we're going to add two new jobs to our gitlab-ci.yml file: prepare_job: stage: prepare image: alpine:latest rules: - if: '$CI_COMMIT_TAG =~ /^v?\d+\.\d+\.\d+$/' script: - apk add curl jq - 'curl -H "PRIVATE-TOKEN: $CI_API_TOKEN" "$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG" | jq -r .notes > release_notes.md' artifacts: paths: - release_notes.md release_job: stage: release image: registry.gitlab.com/gitlab-org/release-cli:latest needs: - job: prepare_job artifacts: true rules: - if: '$CI_COMMIT_TAG =~ /^v?\d+\.\d+\.\d+$/' script: - echo "Creating release" release: name: 'Release $CI_COMMIT_TAG' description: release_notes.md tag_name: '$CI_COMMIT_TAG' ref: '$CI_COMMIT_SHA' assets: links: - name: 'Container Image $CI_COMMIT_TAG' url: "https://$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA" In the above configuration, the prepare_job uses curl and jq to call the GitLab Changelog API endpoint and then passes this to our release_job to actually create the release. To break it down further: We use the project access token created earlier to call the GitLab Changelog API, which performs the generation of the release notes and we store this as an artifact. We're using the $CI_COMMIT_TAG variable as the version. For this to work, we need to be using semantic versioning for our tags (something like 2.0.0 for example), so you'll notice I've also restricted the release job using a rules section that checks for a semantic version tag. Semantic versioning is required for the GitLab Changelog API to work. It uses this format to find the most recent release to compare to our current release. We use the official release-cli image from GitLab. The release-cli is required to use the release keyword in a job. We use the release keyword to create a release in GitLab. This is a special job keyword reserved for creating a release and populating the required fields. We can pass a file as an argument to the description of the release. In our case, it's the file we generated in the prepare_job, which was passed to this job as an artifact. We've also included our container image that is being built earlier in the pipeline as a release asset. You can attach any assets you'd like from your build process, such as binaries or documentation by providing a URL to wherever you've uploaded them earlier in the pipeline. Performing an automated release With this setup, all we need to do to perform a release is push a tag to our repository that follows our versioning scheme. You can simply push a tag using the CLI, this example uses GitLab's UI to create a tag on the main branch. Create a tag by selecting Code -> Tags -> New Tag on the sidebar: On creation, our pipelines will start to execute. The GitLab Changelog API will automatically generate release notes for us as markdown, which contains all the changes between this release and the previous release. Here's the resulting markdown generated in our example: ## 2.0.0 (2023-08-25) ### added (1 change) - [Add ChatBot](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@0c3601a45af617c5481322bfce4d71db1f911b02) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!4)) ### removed (1 change) - [Remove Unused Features](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@463d453c5ae0f4fc611ea969e5442e3298bf0d8a) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!3)) As you can see, GitLab has extracted the entries for our release notes automatically using our git commit trailers. In addition, it's helpfully provided links back to the merge request so readers can see more details and discussion around the changes. And now, our final release: Creating the changelog Next, we want to update our changelog (which is basically a collated history of all your release notes). You can use a POST request to the changelog API endpoint we used earlier to do this. You can do this as part of your release pipeline if you like, for example by adding this to the script section of your prepare job: 'curl -H "PRIVATE-TOKEN: $CI_API_TOKEN" -X POST "$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG" Note that this will actually modify the repository. It will create a commit to add the latest notes to a CHANGELOG.md file: And we are done! By utilizing the rich history provided by git with some handy commit trailers, we can leverage GitLab's powerful API and CI/CD pipelines to automate our release process and generate release notes for us.

Scaling up to enterprise-level intensifies the demand for rapid, secure software delivery. Large organizations can easily fall into the trap of single-function silos, making collaboration tricky and slowing development. Over the past few months, we've introduced new capabilities for the GitLab AI-powered DevSecOps Platform to help teams address these hurdles, accelerate innovation, ensure compliance, and fortify their digital defenses. AI capabilities that reshape speed and security A single, enterprise-ready DevSecOps platform A customizable solution that fits the way you work Let’s take a closer look at what we've been working on and how these advancements benefit growing organizations. Bring the best practices of industry leaders to your team. Join GitLab and Nasdaq for an exciting discussion about AI, DevSecOps, and developer productivity. Register for this webinar today! AI capabilities that reshape speed and security AI will transform the way organizations develop software. Our State of AI in Software Development report, released earlier this year, demonstrates this: 83% of DevSecOps professionals surveyed said implementing AI in their software development processes is essential to avoid falling behind competitors. GitLab Duo is a powerful set of AI capabilities within GitLab’s DevSecOps Platform that helps to speed up development of code, improve operations, and secure software. Since its debut in June, we’ve been steadily expanding the suite of AI capabilities. These now extend across the entire software development lifecycle – from suggesting code, to finding and explaining vulnerabilities in code, to identifying appropriate code reviewers. As enterprises increase code generation, they can avoid potential bottlenecks, such as security checks, further downstream. For example, we recently released our GitLab Duo Vulnerability Explanation feature into Beta. Typically, vulnerability discovery and mitigation would require a significant amount of back-and-forth between development and application security teams to agree on severity levels and approaches to fix the vulnerability. Vulnerability Explanation alleviates this inefficiency by summarizing detected vulnerabilities and their implications as well as providing in-depth solutions and suggested mitigation within the developer’s workflow, enabling faster resolution and creation of safer code within the development workflow. For even more efficiency, GitLab Duo Code Suggestions (Beta) helps developers create new code and update existing code faster. GitLab Duo Suggested Reviewers (generally available to all users) helps teams make an informed decision when choosing reviewers that can meet their review criteria. Learn about all GitLab Duo capabilities. Watch GitLab Duo capabilities in action. A single, enterprise-ready DevSecOps platform Enterprise needs from a software delivery platform are unique. A DevSecOps platform must support the ability to: build for speed with adequate security guardrails right from the start consolidate to a single platform, but still integrate with your existing solution simply adopt and onboard developers, but handle the complexity of scale GitLab CI/CD is a core way for organizations to meet these requirements. As customers scale their adoption of GitLab, they run millions of CI/CD jobs on a monthly basis. With the efficiency improvements further driven by GitLab Duo, these numbers will likely increase. However, organizations will need to find efficiency opportunities throughout their development and deployment workflows to be able to handle this growth, ensuring that whatever is deploying into production meets their quality, security, and reliability standards. The GitLab CI/CD Component Catalog, which will soon be released into Beta, solves these problems by enabling organizations to standardize their pipelines and create building blocks in a centralized repository that can be easily discovered, reused, and shared across teams. Enterprises can develop base pipeline configurations with the proper compliance, quality, and security checks already built-in for use across their organization. Here are some more capabilities aimed at improving the enterprise platform experience: The GitLab Runner ecosystem continues to expand as we've recently introduced GitLab SaaS runners on MacOS, xlarge and 2xlarge SaaS Runners on Linux, increased storage on medium and large SaaS Runners on Linux, and GPU-enabled SaaS Runners on Linux for supporting data science workloads. GitLab Duo, which was previously only available for GitLab SaaS, is now extended to GitLab self-hosted. Enterprises that prefer to self-host or must self-host due to compliance and regulatory restrictions can now take advantage of our AI features, starting with Code Suggestions. Organizations looking at using GitLab Packages as their consolidated package registry can now import packages from their current package registries like Maven Central or Artifactory. GitLab supports importing Maven, npm, NuGet, and PyPI package types into GitLab, with many more package formats to follow. A customizable solution that fits the way you work As companies grow, there is an increasing need to personalize development and deployment settings and provide distinct visibility into the DevSecOps lifecycle to users beyond the immediate DevSecOps teams. GitLab is designed to function effectively with minimal adjustments, yet it offers the flexibility to be tailored to the requirements of expanding organizations. Our recent developments, including changes to product navigation, are driven by comprehensive user research. We recognize that each organization and its individual users have unique, preferred workflows. Our updated navigation features, such as pinning frequently accessed items, visualizing work, and simplifying navigation through fewer top-level items, empower DevSecOps teams to align the platform with their optimal environment and workflow. Watch the new and simplified navigation in action. Here are some other highlights: In addition to overhauling the navigation, we introduced the rich text editor by providing a “what you see is what you get” editing experience. The rich text editor is now available in all issues, epics, and merge requests. GitLab offers six out-of-the-box roles, but for many enterprises this was not enough. Some roles gave too much permission, while others didn’t grant enough permissions to complete a task. Enterprises needed a way to define their own roles – leading to customizable roles, which gives GitLab administrators the ability to define roles with granular permissions suited for their needs. GitLab Value Streams Dashboard ensures that all stakeholders have visibility into the progress and value delivery metrics associated with software development and delivery. To align with customers’ needs to customize the data viewed and the appearance, we introduced new velocity metrics and the ability to customize the appearance and data to adjust metrics based on their areas of interest, filter out irrelevant information, and focus on the data that is most relevant to their analysis or decision-making process. The enterprise awaits — get growing today Organizations on a growth trajectory need a way to sustain that growth. They'll need to leverage the capabilities of AI to generate code faster — but they can't sacrifice quality or security. Organizations will also need to set standards for development and deployment that extend across the enterprise, and every user will need a clear and customizable view of the DevSecOps lifecycle. As we bring new capabilities into the GitLab DevSecOps Platform, we will continue to support these enterprise-class needs. Bring the best practices of industry leaders to your team. Join GitLab and Nasdaq for an exciting discussion about AI, DevSecOps, and developer productivity. Register for this webinar today! Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.