With workspaces, you can create reproducible, ephemeral, cloud-based runtime environments. Since the feature was introduced in GitLab 16.0, the only way to use a workspace was through the browser-based Web IDE running directly in the environment. The Web IDE, however, might not always be the right tool for you.

With GitLab 16.3, you can now securely connect to a workspace from your desktop with SSH and use your local tools and extensions. The first iteration supports SSH connections directly in VS Code or from the command line with editors like Vim or Emacs. Support for other editors such as JetBrains IDEs and JupyterLab is proposed in future iterations.

In previous releases, you probably used kubectl or another third-party tool to check the status of your Flux deployments. From GitLab 16.3, you can check your deployments with the environments UI.

Deployments rely on Flux Kustomization and HelmRelease resources to gather the status of a given environment, which requires a namespace to be configured for the environment. By default, GitLab searches the Kustomization and HelmRelease resources for the name of the project slug. You can customize the name GitLab looks for in the environment settings.

Determining which results from a security or compliance scan are actionable is a significant challenge for security and compliance teams. Granular filters for scan result policies will help you cut through the noise to identify which vulnerabilities or violations require your attention the most. These new filters and filter updates will streamline your workflows:

• Status: Status rule changes introduce more intuitive enforcement of “new” versus “previously existing” vulnerabilities. A new status field new_needs_triage allows you to filter only new vulnerabilities that need to be triaged.
• Age: Create policies to enforce approvals when a vulnerability is outside of SLA (days, months, or years) based on the detected date.
• Fix Available: Narrow the focus of your policy to address dependencies that have a fix available.
• False Positive: Filter out false positives that have been detected by our Vulnerability Extraction Tool, for SAST results, and via Rezilion for our Container Scanning and Dependency Scanning results.

You can now see security findings directly in Visual Studio Code (VS Code), just as you would in a merge request.

You could already monitor the status of your CI/CD pipeline, watch CI/CD job logs, and move through your development workflow in the GitLab Workflow panel. Now, after you create a merge request for your branch, you can also see a list of new security findings that weren’t previously found on the default branch.

This new feature is part of GitLab Workflow for VS Code. Security scan results are pulled from an API, so this feature is available to developers using GitLab.com or self-managed instances running GitLab 16.1 or higher.

The needs keyword is used to define dependency relationships between jobs. You can use the keyword to configure jobs to be dependent on specific earlier jobs instead of following stage ordering. When the dependent jobs complete, the job can start immediately, speeding up your pipeline.

Previously, it was impossible to use the needs keyword to set parallel matrix jobs as dependent, but in this release, we have enabled the ability to use needs with parallel matrix jobs too. You can now define a flexible dependency relationship to parallel matrix jobs, which can help speed up your pipeline even more! The earlier your jobs can start, the earlier your pipeline can finish!

Secrets stored in Azure Key Vault can now easily be retrieved and used in CI/CD jobs. Our new integration simplifies the process of interacting with Azure Key Vault through GitLab CI/CD, helping you streamline your build and deploy processes!