Continuous Integration (travis)

[retostauffer]

Nod really an issue, more a note which might have to be discussed/require adjustments. Had to change some settings regarding travis CI:

*_set_key, *_get_key

To be able to test the set and get key (keyring) I am currently exporting four global variables on travis-ci (ECMWFAPIEMAIL, ECMWFAPIKEY, CDSAPIUSER, and CDSAPIKEY). This allows to load the login details via Sys.getenv(...) within the test scripts, works nicely, but might not be your preferred way. An alternative would be to add encoded variables in the .travis.yml file. The way it is implemented right now allows that different travis CI checks (different users) can use different user accounts (might not be required in the future).

*_key_from_file

One of the extensions is that ~/.ecmwfapirc and ~/.cdsapirc files can be used (as for python ecmwfapi/cdsapi). To be able to run the checks I do have to create them on travis-ci. Thus, .travis.yml calls the create_apirc (https://github.com/retostauffer/ecmwfr/commit/098ffc964b2e0120efd4aded9d5613b177d96997) script (see travis.yml line 14). If on travis-ci the local files will be created based on the global variables (see above).

Works fairly ok, but I do not have too much experience with CI so far.

[khufkens]

Will look into it and fix. Travis CI can be a real pain to get right.

Although In general I feel we should go through wf_get_key() by default setting the environment, not generate a new function to do the same. Currently there is potential for overwriting keys (if not by accident).

So I my idea would be to only use *key_from_file() to populate a keyring using wf_set_key(service = "cds") depending on the content and files available. Basically this should turn this function into wf_rc_to_key() or similar.

Any .netrc or .*rc file in general is a huge security risk (most people forget to set them to user readable only). Using those files shouldn't be encouraged imho, preferring an encrypted keyring instead. However, for those used to the setup the translation function might smooth out the transition to a keyring.

Doing so would also simplify the internal workings of dependent functions (and unit checks) as you don't need to go past two functions only one!

[retostauffer]

After thinking about it I agree with you. It was just convenient for myself and I am the guy not using any key-manager but having some encrypted ASCII files with account information :). vim is life.

I think it will be enough to remove the *_key_from_file feature completely. I mean: those who are able to create a .*rc file in their home folder will also be able to handle the wf_get_key/wf_set_key functions and a "convert my .*rc files once into a registered key" might be more confusing than helpful.

In this case the keyring package has to be a dependency again (I moved to suggested). No issues with keyring support on older servers/Windows/OSX?

[khufkens]

only relying on keyring now...