Skip to content

fix: preserve GitLab advisories with unparsable version strings - #2482

Open
Adnan9-63 wants to merge 1 commit into
aboutcode-org:mainfrom
Adnan9-63:fix-gitlab-importer-version-parsing
Open

Adnan9-63 wants to merge 1 commit into
aboutcode-org:mainfrom
Adnan9-63:fix-gitlab-importer-version-parsing

Conversation

@Adnan9-63

Copy link
Copy Markdown

Summary

Fixes two related data quality bugs in the GitLab Advisory Database v2 importer:


Changes

1. Handle v-prefixed fixed versions (#2411)

  • GitLab advisories frequently include fixed_versions with a leading v (e.g., "v2.0.1"). Some version classes reject this format, causing valid versions to be discarded silently.
  • Normalizes fixed_version strings by stripping the leading "v" prior to calling vrc.version_class().
  • Improved error logging to include the normalized string and package PURL to simplify debugging.

2. Avoid dropping advisories with unparsable version ranges (#2412)

  • Previously, when both affected_version_range and fixed_version_range evaluated to None, parse_gitlab_advisory() returned None, discarding the entire advisory.
  • The pipeline now returns a partial AdvisoryDataV2 instance without affected_packages. This ensures advisory metadata is preserved in the database and can be enriched by downstream improvers.
  • Added a WARNING-level log when storing an advisory without version ranges.

Tests Added

  • test_parse_gitlab_advisory_v_prefix_fixed_version: Validates that a v-prefixed version without an affected_range parses into a valid fixed_version_range.
  • test_parse_gitlab_advisory_unparsable_version_still_stored: Validates that advisories with completely unparsable version strings are retained rather than discarded.

###Note

iam open to learning and all the stuff so if any advice or sujjestion is there or like any mistakes please tell me

Fixes two related data quality bugs in the GitLab v2 importer:

Issue aboutcode-org#2411 - GitLab data source damages package versions:
- GitLab advisories frequently ship fixed_versions with a leading 'v'
  prefix (e.g. 'v2.0.1') that some version classes reject.
- Strip the 'v' prefix before passing to vrc.version_class() so
  parsable versions are no longer silently discarded.
- Improve the error log message to include the normalized form and
  the package PURL for easier debugging.

Issue aboutcode-org#2412 - We do not collect the affected range for GitLab advisories:
- When both affected_version_range and fixed_version_range are None
  the function previously returned None, silently dropping the advisory.
- Return a partial AdvisoryDataV2 (without affected_packages) instead,
  so the record is still stored and can be enriched by downstream
  improvers.
- Emit a WARNING-level log so operators can see which advisories lack
  version data.

Tests added:
- test_parse_gitlab_advisory_v_prefix_fixed_version: verifies that a
  'v'-prefixed fixed version is accepted and produces a valid
  fixed_version_range.
- test_parse_gitlab_advisory_unparsable_version_still_stored: verifies
  that an advisory with a completely unparsable version is not dropped
  (returns AdvisoryDataV2 with empty affected_packages).

Signed-off-by: Muhammad Adnan <muhammad1414114@gmail.com>
Copilot AI balanced review requested due to automatic review settings October 25, 2026 15:15

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

We do not collect the affected range for Gitlab advisories Gitlab data source damages package versions

2 participants