gitlab-org/gitlab-ce v16.2.0

on GitLab

The agentk component of the agent for Kubernetes requires a token to authenticate with GitLab. Previously, you could provide the token as-is, or as a reference to the Kubernetes secret that contains the token. However, you might operate in an environment where the secret is already available in a volume, and prefer to mount that volume instead of creating a separate secret. From GitLab 16.2, the GitLab agent Helm chart ships with this added feature thanks to a community contribution from Thomas Spear.

• Our version of Redis is updated to the latest stable version, 7.0.12.
  
• For fresh installations of GitLab, you can now opt-in to using PostgreSQL 14.
  

Previously, GitLab deployments were linked from the Jira development panel only when a Jira issue
was mentioned in either the branch or merge request associated with the deployment.
This was often inconvenient for users because it required them to deploy
from merge requests, which is not the typical workflow.

With this release, GitLab deployments also scan for Jira issue mentions in the messages of the
last 5,000 commits made to the branch after the last successful deployment. The GitLab deployment is associated with all of the mentioned Jira issues.

Feed tokens have been made more secure by only working for the URL they were generated for. This narrows the scope of feeds that can be read if the token was leaked.

With this release, the GitLab for Slack app is available on self-managed instances. On self-managed GitLab, you can create
a copy of the GitLab for Slack app from a manifest file and
install that copy in your Slack workspace. Each copy is private and not publicly distributable.

To create and configure the app, see GitLab for Slack app administration.

By default, the GitHub importer uses a single access token when importing projects from GitHub to GitLab. An access token for a user account is typically rate limited to
5000 requests per hour. This can significantly reduce the speed of the importer when:

• Importing multiple small to medium sized projects.
  
• Importing a single massive project with a lot of data.
  

With this release, you can pass a list of access tokens to the GitHub importer API so that the API can rotate through them when rate limited.
When using multiple access tokens:

• The tokens cannot be from the same account because they would all share one rate limit.
  
• Tokens must have the same permissions and sufficient privileges to the repositories to import.
  

The built-in backup and restore tool adds the ability to skip specific repositories. The Rake task now accepts a list of comma-separated group or project paths to be skipped during the backup or restore by using the new SKIP_REPOSITORIES_PATHS environment variable. This will allow you to skip, for example, stale or archived projects which do not change over time, saving you a) time by speeding up the backup run, and b) space by not including this data in the backup file.
Thanks to Yuri Konotopov for this community contribution!

By default, Flux synchronizes Kubernetes manifests at regular intervals. Triggering a reconciliation immediately when a manifest changes by default requires additional configuration. With the GitLab agent for Kubernetes, you can push a change to your manifest and trigger a Flux sync automatically.

If you're a power user, using the keyboard to navigate and take action can be frustrating. Now, a new command palette helps you use the keyboard to get more done.

To enable the command palette, open the left sidebar and click Search GitLab (🔍) or use the / key.

Type one of the special characters:

• > - Create a new object or find a menu item
  
• @ - Search for a user
  
• : - Search for a project
  
• / - Search for project files in the default repository branch
  

When you suggest changes in a merge request, you can now edit your suggestions more quickly. In a comment, switch to the rich text editor and use the UI to move up and down the lines of text. With this change, you can view your suggestions exactly as they will appear when the comment is posted.

The rich text editor is a new way of editing in GitLab. It's available in merge requests, but also available alongside the plain text editor in issues and epics.

We plan to have the rich text editor available in more areas of GitLab soon and we are actively working on that. You can follow our progress here.

You can now express your thoughts more creatively by adding emoji
reactions to comments in Design Management.
This feature adds a touch of fun and ease to collaboration, fostering better
communication and enabling teams to provide quick feedback in a more expressive
way.

GitLab 16.2 features an all-new rich text editing experience! This new capability is available for everyone, as an alternative to the existing Markdown editing experience.

For many, using the plain text editor for comments or descriptions is a barrier to collaboration. Remembering the syntax for image references or working with long tables can be tedious even for those who are relatively experienced with the syntax. The rich text editor aims to break down these barriers by providing a "what you see is what you get" editing experience and an extensible foundation on which we can build custom editing interfaces for things like diagrams, content embeds, media management, and more.

The rich text editor is now available in all issues, epics and merge requests. We plan to make it available in more places across GitLab soon. You can follow our progress here.

We are proud of the new editing experience and can't wait to see what you think. Please try the new rich text editor and let us know about your experience in this issue.

For instances which store LFS objects in object storage without proxy download enabled, GitLab now processes LFS requests in bulk. This dramatically improves the performance of downloading a large number of LFS objects.

Previously, due to how LFS objects were fetched, GitLab created many very small requests which checked user permissions and redirected to the object stored externally. This had the potential to cause significant load and a reduction in performance. With this fix, we have reduced load on the primary GitLab instance and provided a faster download experience for our users.

include is one of the most popular keywords to use when writing a full CI/CD pipeline. If you are building larger pipelines, you are probably using the include keyword to bring external YAML configuration into your pipeline.

In this release, we are expanding the power of the keyword so you can use when: never when using rules with include. Now, you can decide when external CI/CD configuration will be excluded when a specific rule is satisfied. This will help you write a standardized pipeline with better ability to dynamically modify itself based on the conditions you choose.

We’re also releasing GitLab Runner 16.2 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:

• Retry all k8s API calls in the runner Kubernetes executor
  

Bug Fixes:

• CI job scripts do not complete when dockerd or any process runs in the background
  
• gitlab-runner-helper servercore image missing for v16.1.0
  
• Error:could not create cache adapter
  

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

Have you been thinking about moving your PyPI repository to GitLab, but haven't been able to invest the time to migrate? In this release, GitLab is launching the first version of a PyPI package importer.

You can now use the Packages Importer tool to import packages from any PyPI-compliant registry, like Artifactory.

GitLab SAST includes many security analyzers that the GitLab Static Analysis team actively maintains, updates, and supports.

During the 16.2 release milestone, our changes focused on the Semgrep-based analyzer and the GitLab-maintained rules it uses for scanning. We released the following changes:

• Clarified the explanation and guidance for JavaScript rules, building on improvements for other languages released in GitLab 16.1
  
• Updated rules to find additional vulnerabilities in Java and JavaScript.
  
• Changed the default configuration for which files are ignored in scans by:
  
  • Removing .gitignore exclusion. Thanks to @SimonGurney for this community contribution.
    
  • Respecting locally-defined .semgrepignore files. Thanks to @hmrc.colinameigh for this community contribution.
    
• Improved a rule related to Go memory aliasing. Thanks to @tyage for this community contribution.
  
• Removed a -1 suffix added to the Semgrep rule IDs for JavaScript rules. This was added in GitLab 16.0 as a side-effect of an unrelated change, but interfered with customers' existing semgrepignore comments.
  

See the semgrep CHANGELOG and sast-rules CHANGELOG for further details.
We're tracking further improvements to GitLab-managed rulesets in epic 10907.

If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates.
To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.

For previous changes, see last month's updates.

We regularly release updates to the GitLab Secret Detection analyzer. During the GitLab 16.2 milestone, we:

• Added GitLab-managed detection rules for:
  
  • OpenAI API keys.
    
  • CircleCI Personal and Project access tokens. Thanks to @nathanwfish for this community contribution.
    
• Improved performance of rules that use the keywords optimization.
  
• Fixed an issue where Secret Detection results created permalinks to the wrong location in the repository.
  

See the CHANGELOG for further details.

If you use the GitLab-managed Secret Detection template (Secret-Detection.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates.
To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.

For previous changes, see the most recent Secret Detection update.

When data scientists create machine learning (ML) models, they often experiment with different parameters, configurations, and feature engineering, so they can improve the performance of the model. The data scientists need to keep track of all of this metadata and the associated artifacts, so they can later replicate the experiment. This work is not trivial, and existing solutions require complex setup.

With machine learning model experiments, data scientists can log parameters, metrics, and artifacts directly into GitLab, giving easy access to their most performant models. This feature is an experiment.

In previous versions of GitLab, when a default branch was fully protected, only project maintainers and owners could push an initial commit to a default branch.

This caused problems for developers who created a new project, but couldn't push an initial commit to it because only the default branch existed.

With the Fully protected after initial push setting, developers can push the initial commit to the default branch of a repository, but cannot push
any commits to the default branch afterward. Similar to when a branch is fully protected, project maintainers can always push to the default branch but no one
can force push.