gitlab gitlab-org/gitlab-foss v16.6.0

latest releases: v17.4.0, v17.4.0-rc42, v16.11.10...
10 months ago

13 new features 2078 total badges

Hide archived projects in search results by default: Global Search

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.

Real-time Kubernetes status updates in the GitLab UI: Deployment Management, Environment Management

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.

Connect to Kubernetes clusters with the GitLab CLI: GitLab CLI, Deployment Management

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.

Private group names are hidden from unauthorized users: Groups & Projects

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.

GitLab Silent Mode (self-managed only): Disaster Recovery

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.

Manage
Comprehensive list of items that failed to be imported: Importers

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.
Consistent navigation experience for all users: Navigation & Settings

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
Create
Minimal forking - only include the default branch: Source Code Management

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.

Verify
CI/CD components Beta release: Pipeline Composition

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!

Improved UI for CI/CD variable management: Secrets Management

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.

GitLab Runner 16.6: GitLab Runner Core

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:

Bug Fixes:

The list of all changes is in the GitLab Runner CHANGELOG.

Package
Prevent duplicate NuGet packages: Package Registry

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.

Upload packages to the Maven repository with basic HTTP authentication: Package Registry

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.

Don't miss a new gitlab-foss release

NewReleases is sending notifications on new releases.