Skip to content

Update the `maven-metdata.xml`when a package is deleted

Summary

Deleting a package from a project's maven repository doesn't remove it from the maven-metadata.xml. This can cause problems with how dependencies are resolved.

Steps to reproduce

  1. Publish a version of an artifact to a project's maven repository.

  2. Verify that it appears in the output of these commands:

    curl -H "Private-Token: $PAT" \
  https://gitlab.com/api/v4/projects/$PROJ_ID/packages/maven/com/example/artifact_id/maven-metadata.xml
curl -H "Private-Token: $PAT" \
  https://gitlab.com/api/v4/groups/$GROUP_ID/-/packages/maven/com/exaple/artifact_id/maven-metadata.xml

    Note that:

    • $PAT is a private access token that can access the maven repository.
    • $PROJ_ID is the numeric project ID.
    • $GROUP_ID is the group ID.
    • com/example is the slashified maven group ID (for com.example in this example)
    • artifact_id is the maven artifact ID

  3. Verify that it also appears on the page https://gitlab.com/$GROUP_ID/$PROJECT_SLUG/-/packages in your browser.

  4. Delete that version of the artifact.

It will now be removed from the UI, but will still appear in the output of the above curl commands.

Proposal

Update the existing metadata xml file

  • When a destructive operation is done, enqueue a background job to update the existing maven-metadata.xml files
    • This solves issue (1.)

The background job will need to search for the versionless packages, fetch the proper maven-metadata.xml file and update it accordingly.

For maven packages

  • Update the <latest>, <release> and <versions> sections
  • Update the <lastUpdated> accordingly.
    • We can take time.now for this.

For maven plugins

  • Do the above for the maven-metadata.xml at the groupId + artifactId level
  • Update the <plugins> sectopm for the maven-metadata.xml at the groupId level

Upsides:

  • Relatively simple solution to implement: a single background job
    • The background job can handle both packagings: maven packages and maven plugins.
  • No performance concerns here, as we would work at the project level all the times
  • Short MR plan
    MR Weight
    Background worker to update the maven metadata xml file 2

Downsides:

  • Changes are not available right after the destructive action: the background job has to run
    • The background job has to
      1. download the xml file (⚡ network request)
      2. update its contents
      3. upload the updated content (⚡ network request)
Edited by Tim Rizzi