Home → Suggestions →

provide command-line clients (sim. to sqlcmd.exe) for PostgreSQL and MySQL database targets

• Edit

sbohlen

31 Dec, 2014 04:28 AM

In the same way that adding SQL Server to my CI build installs sqlcmd.exe and adds it to the %PATH% so its easily-accessible to the build process for scripting interaction with the database (e.g., create database, create tables, fill them with data), I'd like to recommend that you consider adding the similar command-line utilities for the other databases you support (e.g., mysql.exe for MySQL and psql.exe for PostgreSQL).

In their absence as part of your worker image, I've added these binaries to my source repo in a /tools/<database>/bin/ folder so that they are accessible to my build process running on your systems, but this swells the size of my repo and increases the overhead of the the initial PULL that Appveyor is doing on each of my builds. It also means that *I* have to keep these bins version-aligned with that of the actual databases which you're supporting at any given moment.

Its trivially easy for you to get these utils into your image(s); you needn't actually _install_ these things but instead you can just download the ZIP (archive) format file from each database project and just copy the contents of the /bin/ folders in each .zip into an appropriate spot in your build image(s). This is basically how I got the contents of the /tools/ folder in my project (https://github.com/NDbUnit/NDbUnit/tree/master/tools). Since we don't really need the _full_ content of the /bin/ folders in the archive packages from the DB vendors/projects, you can see how I've essentially pruned many of the unnecessary files from my /tools/<database>/bin/ folders to at least try to reduce their size (a bit).

Also, along this same direction, if/when you resolve https://github.com/appveyor/ci/issues/31 and add ORA XE support, it would similarly be great if you'd add the sqlplus.exe command-line util for ORA in the same way (again, so that its easy to script setup, etc. of the ORA XE database targets as well).

Thanks again for all the hard work on this system/site/product overall -- I'm really enjoying the general ease-of-use and the thinking that went into each of the configuration/integration points. For example to get the password into the psql.exe util for Postgres, I discovered that I needed to add a PGPASSWORD environment variable and was pleased to discover that you offer an extension point for doing just that with only a few mouse-click; nice work!

Cheers,

-Steve B.

1. Support Staff 1 Posted by Feodor Fitsner on 31 Dec, 2014 06:03 AM

   

   Hi Steve,

   Thanks for your suggestion and kind words - it's a real pleasure you like the service!

   Both MySQL and PG command-line tools are there - they are just not in the PATH by default.

   However, you can access them by the following paths:

   C:\Program Files\MySql\MySQL Server 5.6\bin\mysql.exe
   C:\Program Files\PostgreSQL\9.3\bin\psql.exe
   

   I'll update docs with their paths.

   To add them to PATH just add this to "install" section of your project:

   SET PATH=C:\Program Files\MySql\MySQL Server 5.6\bin;C:\Program Files\PostgreSQL\9.3\bin;%PATH%
   

   Let me know if you have any questions.

   • Edit

2. 2 Posted by sbohlen on 31 Dec, 2014 12:02 PM

   

   Ha -- great! TBH, I never thought to search the disk for the full installs of the products :)

   I think I was assuming they weren't there b/c you _do_ add the /bin/ folder for SQL Server to the %PATH% when I add that service so I just assumed that you'd do the same for the other DBs as well if they are added. When they didn't appear on the %PATH% for me, I just assumed it was b/c you'd excluded them from the install scope for these other products.

   As you suggest, knowing their location clearly enables me to solve this problem for myself by appending them to the %PATH% variable. I agree that adding these paths to the docs would def. go a long way to helping others avoid some of the more annoying work-arounds I'd implemented (e.g. adding the corresponding bins to my own source repo).

   But all the same, I'm honestly curious: why treat SQL Server differently in re: putting it on the path for me but require me to patch %PATH% myself for the tools for the other databases? I'd imagine that my use-case (using command-line client tools for each DB to invoke pre-test scripts) is a pretty common use-case for anyone standing up a DB for integration tests as part of their test suite...

   Is it a conscious choice you're making or more just a side-effect of the SQL Server installer automatically adding itself to %PATH% whereas the installers for the other DBs might not be doing so too --?

   Meantime, I'll certainly remove the bins from my source repo and tweak %PATH% locally for my near-term needs ASAP.

   Thanks (as always!) for the speedy response!

   Cheers,

   -Steve B.

   • Edit

3. Support Staff 3 Posted by Feodor Fitsner on 31 Dec, 2014 06:25 PM

   

   Right, most probably SQL Server bin folder was added to PATH by the installer (or by some other tool).

   • Edit

4. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 01:53 AM.