Skip to content

Support NuGet version normalization

Moaz Khalifa requested to merge 273697-support-nuget-normalized-versions into master

What does this MR do and why?

Problem

Suppose we have a NuGet package named Hello in our GitLab NuGet Repository with version 1.0.7.0. If we tried to pull it using NuGet 3.4+, you would get the following error:

Package 'Hello.1.0.7' is not found on source 'https://example.gitlab.com/api/v4/projects/<your_project_id>/packages/nuget/index.json'.

Notice the version in the error message: it's different than the package's version stored in GitLab's NuGet Repository. The reason is that NuGet 3.4+ normalizes the version number and then sends the normalized string to the NuGet Repository. We try to search for the package using the received normalized version and we don't find the package. Makes sense.

Solution

In this MR, the following solution has been introduced:

  • Create a new column normalized_version in the packages_nuget_metadata table
  • Add Packages::Nuget::NormalizeVersionService to apply normalization rules on the version string.
  • When a new package is created, we save the normalized version in packages_nuget_metadata 's normalized_version column using a before_validation callback in the Packages::Nuget::Metadatum model.
  • Update Packages::Nuget::PackageFinder to search for packages using LOWER(version) or packages_nuget_metadata 's normalized_version.
  • Get rid of ILIKE fuzzing matching in Packages::Nuget::PackageFinder in favor of exact matching to enhance the performance. NuGet client always sends the package's full name so exact matching would suffice.
  • In a subsequent MR, I will introduce a background migration to backfill the normalized_version for the existing NuGet Repository packages.
  • Changes are behind the nuget_normalized_version feature flag.

How to set up and validate locally

  1. Ensure you have the NuGet CLI installed (see nuget docs for links to installation pages).

  2. In a new directory, run nuget spec.

  3. Update the version in the Package.nuspec file to 1.0.7.0.

  4. Run nuget pack in the same directory, you should find a generated file named Package.1.0.7.nupkg.

  5. Notice the NuGet CLI automatically normalized the version to 1.0.7, we need to update the version manually so that we can push the package with the unnormalized version 1.0.7.0:

    1. Run unzip Package.1.0.7.nupkg, and allow the .nuspec file to be replaced.
    2. Edit the .nuspec file and set the version to 1.0.7.0
    3. Compress/zip all of the files in the folder except for Package.1.0.7.nupkg.
    4. Rename the zip archive Package.1.0.7.0.nupkg.

  6. Add a GitLab project as your NuGet source:

    nuget source Add -Name localhost -Source "http://gdk.test:3000/api/v4/projects/<project_id>/packages/nuget/index.json" -UserName <gitlab_username> -Password <personal_access_token>

  7. In rails console, enable the nuget_normalized_version feature flag before publishing the package:

Feature.enable(:nuget_normalized_version, Project.find(<project_id>))

  1. Push the package to your project:

    nuget push Package.1.0.7.0.nupkg.zip -Source localhost

  2. In the UI, navigate to the project, and go to Packages & Registries -> Package Registry. You should see the NuGet package published with version 1.0.7.0.

  3. Create packages.config file in the directory of the published package:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Package" version="1.0.7.0" />
</packages>
  1. Execute the command: nuget restore -PackagesDirectory . -Source localhost
  2. The package should be pulled successfully.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Database analysis

Related to #273697 (closed) & #270976 (closed)

Edited by Moaz Khalifa

Merge request reports