snowflakedb/snowflake-cli

SNOW-1209103: Connecting using only env variables doesn't seem to work

Closed this issue · 7 comments

SnowCLI version

2.0.0

Python version

3.10

Platform

ubuntu x86

What happened

I'm trying to build a GitHub action that connects using Snowflake CLI. I'm defining these env:

env:
  SNOWFLAKE_CONNECTIONS_GH_ACCOUNT: ${{ secrets.ACCOUNT }}
  SNOWFLAKE_CONNECTIONS_GH_USER: ${{ secrets.USER }}
  SNOWFLAKE_CONNECTIONS_GH_PASSWORD: ${{ secrets.PWD }}
  SNOWFLAKE_CONNECTIONS_GH_DATABASE: ${{ secrets.DATABASE }}
  SNOWFLAKE_CONNECTIONS_GH_SCHEMA: ${{ secrets.SCHEMA }}
  SNOWFLAKE_CONNECTIONS_GH_WAREHOUSE: ${{ secrets.WAREHOUSE }}
  SNOWFLAKE_CONNECTIONS_GH_ROLE: ${{ secrets.ROLE }}
  SNOWFLAKE_OPTIONS_DEFAULT_CONNECTION: GH

However when the action runs

snow connection test -c GH

The action returns an error "Connection GH is not configured".

I don't really want any config file in a github action, and expected since I'm defining all connection attiritbutes as env that it would still work, but Iw wonder if it still is checking the file first?

Console output

No response

How to reproduce

No response

A workaround I have used is to fake out the config file with a stub passed through shell substitution:

export SNOWFLAKE_CONNECTIONS_DEFAULT_ACCOUNT=""
export SNOWFLAKE_CONNECTIONS_DEFAULT_USER=""
export SNOWFLAKE_CONNECTIONS_DEFAULT_PASSWORD=""
export SNOWFLAKE_CONNECTIONS_DEFAULT_DATABASE=""
export SNOWFLAKE_CONNECTIONS_DEFAULT_SCHEMA=""
export SNOWFLAKE_CONNECTIONS_DEFAULT_WAREHOUSE=""

snow --config-file <(echo "[connections.default]") connection test

Downside is that a warning is emitted:

UserWarning: Bad owner or permissions on /dev/fd/63.
 * To change owner, run `chown $USER "/dev/fd/63"`.
 * To restrict permissions, run `chmod 0600 "/dev/fd/63"`.

  warn(f"Bad owner or permissions on {str(filep)}{chmod_message}")

Would be awesome if the fake config was not needed

Thanks @sfc-gh-vtimofeenko for workaround in meantime

@sfc-gh-turbaszek can we check on this dependency on config.toml ? I believe one of the options we were looking to add a auto generate one in this case where system passes all info as env var to CLI ?

In 2.1.0 this is addressed by using --temporary-connection/-x with support for generic connection variables like SNOWFLAKE_PASSWORD, SNOWFLAKE_ACCOUNT etc.

Yep, seems to work without ~/Library/Application Support/snowflake/config.toml:

❯ direnv reload .
direnv: loading /private/var/folders/lx/20zv3yk14bsdmy2f3qvvssgh0000gn/T/tmp.OYrEsPsIrf/.envrc                                          
direnv: export +SIS_GRANT_TO_ROLE +SIS_QUERY_WAREHOUSE +SNOWFLAKE_ACCOUNT +SNOWFLAKE_DATABASE +SNOWFLAKE_PASSWORD +SNOWFLAKE_ROLE +SNOWFLAKE_SCHEMA +SNOWFLAKE_USER +SNOWFLAKE_WAREHOUSE

❯ ./bin/snow --version
Snowflake CLI version: 2.1.0rc1

❯ echo 'SELECT 1'  | ./bin/snow sql -x -i                       
SELECT 1
+---+
| 1 |
|---|
| 1 |
+---+

Would it be possible to move --temporary-connection/-x flag to the root of the command options, so one could a single wrapper for CI/CD that needs to invoke snowcli several times with different subcommands? So instead of snow sql -x -i it would be snow -x sql -i or snow -x streamlit deploy.

My main question is why not use config.toml on CI/CD? There are multiple pros for it:

  1. Predefined connections details
  2. Possibility to share the connections
  3. Explicit information what config is used via --config-file
  4. Reduced number of env variables to only mandatory ones
  5. Predefined configuration for other things than connections for example logging, plugins etc

This is how we are running our integration and e2e tests.

Closing as this seems to be fixed. If needed we can continue the discussion using discussions 👌