@carl-westman_8110 said in Getting 500, "Could not find stored procedure 'Security_GetRoles', but /health show no errors:

Unhandled exception

i don't see those, only the XX000: cache lookup failed for type exceptions

it returns code 200, so i assume yes

I same problem but a different error:

2025-09-19T11:31:52.055874602+02:00 info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
2025-09-19T11:31:52.055917374+02:00       Request starting HTTP/1.1 GET http://proget.xxx.de/ - - -
2025-09-19T11:31:52.058745038+02:00 An error occurred in the web application: XX000: cache lookup failed for type 641322
2025-09-19T11:31:52.110076806+02:00 info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
2025-09-19T11:31:52.110107728+02:00       Request finished HTTP/1.1 GET http://proget.xxx.de/ - 500 0 - 54.3259ms

2025-09-19T11:30:23.356843497+02:00 Running Connector Cache Check...
2025-09-19T11:30:23.369384274+02:00 Getting list of connector responses...
2025-09-19T11:30:23.381026135+02:00 Unhandled exception: XX000: cache lookup failed for type 641314

Downgrading to 25.0.9 doesn't help. I recently migrated to integrated PostgreSQL.

This is the error i get:

"options": {
      "headers": {
        "user-agent": "Renovate Bot (GitHub App 2740)",
        "accept-encoding": "gzip, deflate",
        "authorization": "***********",
        "accept": "application/json"
      },
      "url": "https://proget.inedo.com/v2/productimages/inedo/proget/tags/list?n=10000",
      "username": "",
      "password": "",
      "method": "GET",
      "http2": false
    },
    "response": {
      "statusCode": 500,
      "statusMessage": "Internal Server Error",
      "body": null,
      "headers": {
        "cache-control": "public, max-age=300",
        "content-type": "application/json; charset=utf-8",
        "content-encoding": "gzip",
        "vary": "Authorization",
        "server": "Microsoft-IIS/10.0",
        "x-proget-version": "5.3.27.18",
        "docker-distribution-api-version": "registry/2.0",
        "x-aspnet-version": "4.0.30319",
        "x-powered-by": "ASP.NET",
        "date": "Wed, 21 Apr 2021 05:57:33 GMT",
        "connection": "close",
        "content-length": "84"
      },
      "httpVersion": "1.1"
    }
  }

Seeing 500 on https://proget.inedo.com/containers/registry?feedId=22.

Maybe that is related?

I know, i saw that difference. Just wanted to inform you

It's now always dooing upgrade

ProGet version is 5.3.24.7.
Current DB schema version is 5.3.24.
Executing untracked script DDL-DML/0000. Untracked/10. Block 5.3 Upgrades.sql...
Executing untracked script DDL-DML/0000. Untracked/10. Block SQL Server 2005.sql...
Tracked script DDL-DML/v1-3/0002. 0.1.0/10 SET DATABASE PROPERTIES.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/20 CREATE TYPES.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/21 CREATE ROLE ProGetUser_Role.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30 CREATE TABLE Configuration.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30 CREATE TABLE Environments.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30CTC1 CREATE TABLE Connectors.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30CTC2 CREATE TABLE ConnectorFilters.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30EVT1 CREATE TABLE EventTypes.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30EVT2 CREATE TABLE EventTypeDetails.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30EVT3 CREATE TABLE EventOccurences.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30EVT4 CREATE TABLE EventOccurenceDetails.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30USR1 CREATE TABLE Groups.sql has already been executed; skipping...

It should skip updates update at all if already uptodate, otherwise startup will be very slow

@viceice said in [ProGet] Manual database upgrade (docker, kubernetes):

upgradedb

needs to be ProGet.Service upgradedb. fixed it in my pr

getting this when trying to run upgrade command

For help on a specific command, type: ProGet.Service help [command]
To run interactively, type: ProGet.Service interactive
Invalid command: upgrade

ProGet.Service 5.3.24.7
Usage: ProGet.Service [command]

Commands:
run Runs the ProGet service and/or the ProGet web server interactively.
install Installs the ProGet service as a Windows service.
uninstall Uninstalls the ProGet Windows service.
resetadminpassword Switches to the built-in user directory and changes the Admin account password to "Admin".
upgradedb Upgrades the database schema version to this version of ProGet.

For help on a specific command, type: ProGet.Service help [command]
To run interactively, type: ProGet.Service interactive

https://github.com/Inedo/inedo-docs/pull/223

The issue is closed, so can i implement it to my kubernetes deployment?

ok, database upgrade command can be run in init_container (wicch can be without any probes)

here a new sample:

kind: StatefulSet
apiVersion: apps/v1
metadata:
  name: proget
  namespace: services
  labels:
    app: proget
spec:
  replicas: 1
  selector:
    matchLabels:
      app: proget
  template:
    metadata:
      labels:
        app: proget
    spec:
      volumes:
        - name: packages
          emptyDir: {} # should be pvc
        - name: extensions
          emptyDir: {} # should be pvc
      init_container:
        - name: upgrade-db
          image: 'ghcr.io/visualon/proget:5.3.21'
          command: ["/usr/local/proget/service/ProGet.Service.exe", "upgrade"] # Updates the database if required
          env:
            - name: SQL_CONNECTION_STRING
              value: Data Source=proget-sql; Initial Catalog=ProGet; User ID=sa; Password=<YourStrong!Passw0rd> # should be come from secret
          volumeMounts:
            - name: packages
              mountPath: /var/proget/packages
            - name: extensions
              mountPath: /var/proget/extensions
      containers:
        - name: proget
          image: 'ghcr.io/visualon/proget:5.3.21'
          ports:
            - containerPort: 80
              protocol: TCP
          env:
            - name: SQL_CONNECTION_STRING
              value: Data Source=proget-sql; Initial Catalog=ProGet; User ID=sa; Password=<YourStrong!Passw0rd> # should be come from secret
          volumeMounts:
            - name: packages
              mountPath: /var/proget/packages
            - name: extensions
              mountPath: /var/proget/extensions
          livenessProbe: # additional startupProbe and readyness probes are available
            httpGet:
              path: /log-in
              port: 80
            initialDelaySeconds: 15
            periodSeconds: 5
  serviceName: proget

This will call the database update command with an init container which has no timeouts. After that is done (exit code zero), kubernetes will start the normal container(s) which can skip upgrade, as it's aready done.

So an proget upgrade would simply be an image update

probes: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes

So the init container runs before the normal proget container.

Normally the proget container gets some startup and liveness probes, if they fail proget will be restartet.

So if i upgrade the image and a database update is needed, this would currently trap theed by the probes and i get an endless restart loop.

Of cause i can extend the startup probes timeout, but that would cause a lot of failues in kubernetes logs.

It would be nice, if there is a possibillity to check the version and only run the update if the version doesn't match.

here a simplified stateful set:

kind: StatefulSet
apiVersion: apps/v1
metadata:
  name: proget
  namespace: services
  labels:
    app: proget
spec:
  replicas: 1
  selector:
    matchLabels:
      app: proget
  template:
    metadata:
      labels:
        app: proget
    spec:
      volumes:
        - name: packages
          emptyDir: {} # should be pvc
        - name: extensions
          emptyDir: {} # should be pvc
      init_container:
        - name: upgrade-db
          image: 'ghcr.io/visualon/proget:5.3.21'
          command: ["/usr/local/proget/db/inedosql", "update", "/usr/local/proget/db/SqlScripts.zip"] # should only update if required
          env:
            - name: SQL_CONNECTION_STRING
              value: Data Source=proget-sql; Initial Catalog=ProGet; User ID=sa; Password=<YourStrong!Passw0rd> # should be come from secret
          volumeMounts:
            - name: packages
              mountPath: /var/proget/packages
            - name: extensions
              mountPath: /var/proget/extensions
      containers:
        - name: proget
          image: 'ghcr.io/visualon/proget:5.3.21'
          ports:
            - containerPort: 80
              protocol: TCP
          env:
            - name: SQL_CONNECTION_STRING
              value: Data Source=proget-sql; Initial Catalog=ProGet; User ID=sa; Password=<YourStrong!Passw0rd> # should be come from secret
          volumeMounts:
            - name: packages
              mountPath: /var/proget/packages
            - name: extensions
              mountPath: /var/proget/extensions
  serviceName: proget

@atripp Simply running the upgrade didn't help, as the services is upgrading again because the new version is missing in the database.

So it would really helpful to have a simple upgrade command which can be run before running the service.

OK, found this and will try

docker run --rm -it proget:5.3.21 /usr/local/proget/db/inedosql update /usr/local/proget/db --connection-string="...."

Ok, can use inedosql_cs env for connection string

https://github.com/Inedo/inedosql/blob/41550402277bbf468583d3346bb0458d55f5a482/inedosql/Program.cs#L314

Yes, a initContainer runs before the normal container and should simply exit with code 0 when done or any other exit code to indicate a failure.

I already have a kubernetes deplyoment and can easily add an init container myself. So i only need a way to call the inedosql before running the normal proget service.

I've checked the image contents and found the indedosql at /usr/local/proget/db can i simply override the docker entrypoint an call that executable? Do i need any special commands args?

I'm using the proget image in a kubernetes deployment.

Currently i have some trouble when auto upgrading the database. This will sometimes timeout in my startup probe.

So my idea is to run the database upgade as an InitContainer with other limits. So the normal proget container can startup without migration.

Is there any ways to run the proget docker image to only upgade the database and then exit?

I'm not sure which package causes this issue, but the packages are all public, see https://github.com/orgs/visualon/packages

I'm pretty sure it was one of those packages:

You need a github account to use the feed above, because github requires you to login.
So i think you should be able to reproduce the issue.

Today i got some proget errors from my github package connector:

System.NullReferenceException: Object reference not set to an instance of an object.
at Inedo.ProGet.Feeds.NuGet.NuGetConnector.FindPackagesByIdAsync(NuGetQueryOptions options, String id) in C:\InedoAgent\BuildMasterTemp\192.168.44.60\Temp\_E91433\Src\ProGetCoreEx\Feeds\NuGet\NuGetConnector.cs:line 296

My connector:

Using ProGet on Docker for Linux: Version 5.3.19 (Build 9)

proget.inedo.com/productimages/inedo/proget:5.3.19@sha256:03b64607a3c7be571bc37acec8965efa05723994678d8f99ecac6e45d7ae8c53