Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

Docker env variable SQL_CONNECTION_STRING_FILE not being used



  • This is with the ProGet v22 image from proget.inedo.com/productimages/inedo/proget:22.0.7.

    The docs say that you can specify an environment variable SQL_CONNECTION_STRING_FILE with the connection string as the file text, but when I use this variable, it has no effect. If I use SQL_CONNECTION_STRING instead with the connection string, then this works fine.

    My docker compose file looks something like:

    services:
      proget:
        environment:
          - SQL_CONNECTION_STRING_FILE=/run/secrets/mssql-cs
    
    secrets:
      mssql-cs:
        file: ./secret.txt
    

  • inedo-engineer

    Hi @jeff-peirson_4344 ,

    Looks like the docs were wrong, thanks for bringing that up.

    It should be PROGET_SQL_CONNECTION_STRING_FILE -- I've since updated the docs.

    Cheers,
    Alana



  • @atripp I've updated the var name, but I'm still unable to get this working.

    I can verify the the secret file exists and has the correct text in the container by running cat /run/secrets/mssql-cs. Also, I oversimplified my pasted docker compose file - it does correctly include the secret under the proget service, and I've since updated it with the correct env var name:

    services:
      proget:
        secrets:
          - mssql-cs
        environment:
          - PROGET_SQL_CONNECTION_STRING_FILE=/run/secrets/mssql-cs
    
    secrets:
      mssql-cs:
        file: ./secret.txt
    

    Does the file require certain permissions to be recognized by the ProGet service? Should the file text be the literal connection string, no quoting, no trailing newline? What happens if this env var is set, but the file does not exist?

    I don't think ProGet is trying to read the file, because if I provide an invalid connection string, like server6=mssql;..., I'd expect to see connection string parse error in the ProGet log, but instead I just see, "A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections" which I'm assuming means ProGet is using a default connection string to localhost or something.


  • inedo-engineer

    @jeff-peirson_4344 - I just ran a test and verified the behavior. ProGet does the following on startup to determine the connection string (in this order):

    1. look for SQL_CONNECTION_STRING environment variable (this was the old documented name)
    2. look for PROGET_SQL_CONNECTION_STRING environment variable
    3. look for PROGET_SQL_CONNECTION_STRING_FILE variable

    The first of those with a non-empty and non-whitespace-only value is used. The connection string file requires only read access, and must be plain text containing only the connection string with no additional quoting or escaping. Empty lines are ignored - the first non-empty line is used as the connection string, and any trailing newlines are ignored.

    Our Dockerfile does specify a default PROGET_SQL_CONNECTION_STRING, so you may need to override that to be empty. Perhaps it would make more sense if we checked for the file first - I'll discuss that with the team.

    Hope this helps!



  • @gdivis That was it - I had to override PROGET_SQL_CONNECTION_STRING.

    I had to override it as:

      environment:
        - "PROGET_SQL_CONNECTION_STRING= "
        # would fail:
        #- PROGET_SQL_CONNECTION_STRING=
        - PROGET_SQL_CONNECTION_STRING_FILE=/run/secrets/mssql-cs
    

    Else startup would fail with "System.ArgumentNullException: Value cannot be null. (Parameter 'connectionString')"

    In any case, I have a working docker compose file now - thanks!


Log in to reply
 

Inedo Website HomeSupport HomeCode of ConductForums GuideDocumentation