Navigation

    Inedo Community Forums

    Forums

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    1. Home
    2. kemeny.attila_7338
    3. Posts
    K
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    Posts made by kemeny.attila_7338

    • Update failed to Proget 5.1.23

      Hello,

      we are currently using Proget 5.1.2 and we would like to update ProGet to the latest version 5.2.26 but the update failed.
      So we tried which version broke the update. And there was no problem to upgrade untile the version 5.1.22. But when we tried to install the 5.1.23 version it didn't start.
      Inspecting the logs from the previous successful install and the failed one, there is two errors during the 'Executing additional scripts...' step.

      .
      .
      .
        2.VIEWS/1.NuGetPackagesV2_Latest.sql...
        2.VIEWS/1.NuGetPackagesV2_LatestStable.sql...
      42703: column np2.Lower_Package_Id does not exist
      42703: column np2.Lower_Package_Id does not exist
        2.VIEWS/1.NuGetPackageSymbolsV2_Extended.sql...
      42703: column np2.Lower_Package_Id does not exist
        2.VIEWS/1.NuGetPackageVersionsV2_Extended.sql...
      42703: column np2.Lower_Package_Id does not exist
        2.VIEWS/1.PackagePromotions_Extended.sql...
        2.VIEWS/1.Packages_Combined.sql...
      .
      .
      .
      

      I also attach the two logs:

      • the first log is to update to 5.1.22 which was successful
      • the second log is the update to 5.1.23 which wasn't.

      We are unable to install any newer version of Proget than 5.1.22 which is now a major problem for us as we would like to use the new helm chart repository.

      We run Proget from an Ubuntu container and the database is an Azure Hosted Postgres.

      Can you help us investigate and solve this issue?

      Thank you!
      Attila

      posted in Support
      K
      kemeny.attila_7338
    • RE: `dotnet nuget push --skip-duplicate` does not work as expected

      I found this thread while looking for solution of the exact same problem to OP has.
      In our case this feature is not essential but a nice-to-have. For example when the CI pipeline is broken after the nuget artifact was pushed, rerun the build will fail again at the step of nuget push. With this settings all builds could be idempotent and could be run as many times as necessary. Which is a big plus for us.

      I understand you don't want to do changes which are not backward compatible. Isn't it possible to add an option or settings where the user can choose the HTTP response code of the response when the package is already exists? In this case if the default value is 403, the change will be backward compatible and can be release faster.

      posted in Support
      K
      kemeny.attila_7338
    • 1 / 1