Publishing Nuget package fails (Self-hosted / SaaS)

Publishing Nuget package fails in self-hosted gitlab instance

We’re suddenly getting:

There was an error publishing a NuGet.Temporary.Package package
There was a timeout and the package was not published. Delete this package and try again.


The build output has no indication of any errors:

Since we update every friday and publishing seemed to work a week ago (14th feb) I can’t help but think something broke in 16.9. I have updated to 16.9.1 in the hopes this would fix it but it didn’t. Note: I’m not saying 16.9.x broke something, I just don’t have any idea what else changed. I’ve checked wether maybe the disk was full but it has plenty space (36GB).

Steps to reproduce

Which troubleshooting steps have you already taken? Can you link to any docs or other resources so we know where you have been?


We use the following CI config:


image :


  - build
  - test
  - package


  stage: package
    - dotnet nuget add source "${CI_API_V4_URL}/projects/${NUGET_CI_PROJECT_ROOT_ID}/packages/nuget/index.json" --name gitlab --username gitlab-ci-token --password $CI_JOB_TOKEN --store-password-in-clear-text
    - dotnet test -c Release
    - dotnet pack $PROJECTNAME -c Release -o artifacts /p:Version="${CI_COMMIT_TAG}"
    - echo "$CI_COMMIT_TAG-$CI_COMMIT_SHA" >> artifacts/version
    - dotnet nuget push "artifacts/*.nupkg" --source gitlab
      - artifacts
    expire_in: 2 days
    - tags

But the problem is the same when we publish from the commandline:

dotnet nuget push "FooProject.1.2.3.nupkg" --source "" -api-key glpat-XXXXXXXXXX


Please select whether options apply, and add the version information.

  • Self-managed
  • SaaS
  • Self-hosted Runners
Component Version
GitLab Shell 14.33.0
GitLab Workhorse v16.9.1
GitLab API v4
GitLab KAS v16.9.2
Ruby 3.1.4p223
Rails 7.0.8
PostgreSQL (main) 13.13
PostgreSQL (ci) 13.13
Redis 7.0.15

Helpful resources

  1. I’ve tried googling but didn’t find much. I did find this but that was back in 14.x and should be fixed.
  2. I’ve also tried searching the forums but couldn’t find anything relevant.
  3. I have nothing but a hunch that the “Timeout” mentioned is not correct; after the push is ran the message appears (seemingly) immediately - within seconds. I’d expect a time to be something like 10 or 30 seconds or so.
  4. I wish I had a clue on where to look in which logfile to maybe figure out what is going on, but I have no clue where to look.

I should’ve thought about this sooner: I’m running another self-hosted gitlab instance at home at 16.9.0. I’ve succesfully pushed the package from the CLI on it and that works fine, it shows up in the registry. Updated to 16.9.1 and it still works. So I don’t think the problem is in the latest update(s), but that’s actually kind of not so good news. That means something else broke and I don’t have the slightes clue where to look to figure out what is wrong, what is “timing out”.

I’ve also tried to create a new repository and upload a package there, but I still get the error:

There was an error publishing a NuGet.Temporary.Package package

There was a timeout and the package was not published. Delete this package and try again.

Things I have tried, all with the same result (still same error after):

  • Comparing metadata for packages before and after problems started: no difference
  • LOTS of permutations of uploading a package (including curl commands, other hosts, different packages with different versions / metadata)
  • Create a new (empty) package-repository
  • Used Fiddler to ‘sniff’ the (https) network traffic: Upload succeeds, I get a “201 Created”, yet: still same error
  • Updated Debian Bullseye to Bookworw (which was a difference between the home instance and work instance)

I am really at loss here.

When I upload a package from the commandline using dotnet nuget push ... I get a 201 created which, to me, at least indicates that the upload worked and the package was accepted. I’m not sure what happens after, but somewhere between ‘accepting’ the upload an the package actually appearing in the repository is the problem I guess. Unfortunately I still have no clue where to look in what logfiles (if any).

It turns out the upload fails whenever the projectUrl (and/or licenseUrl) contain the actual hostname of the Gitlab host. I have created an issue that goes into more detail.

1 Like

Confirmed on my side,

It happens on SaaS and self-managed

Thanks for the solution!

1 Like

Please leave the same reply in the issue (or upvote the issue or…).