-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix bug where -n and -k was mutually exclusive #281
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do the insecure and cacert options work correctly if you specify them along with a saved server? I'd expect them to override the saved server's settings.
Summary: stored > cli > environment Per discussion, to facilitate existing user workflows, we will make non-empty stored credentials take precedence over CLI and environment credential variables. This will revert the behavior back to version <= 1.9.x.
|
on the rsconnect-python
|
I also found a new issue related to storing creds: |
When deploying with
|
fixed by 7a14e71
The UserWarning is intentional. Although it can probably show up better. |
I was referring to the: |
Oh ok, gotcha. This should be better: c163e89 |
Do we need all of this for a warning?
Can we just print out only the necessary text, i.e: Connect will use non-empty stored credentials. CLI & environment credentials are ignored The warning doesn't stand out very well against all the text. |
Adding a server with no api key now fails. Is that the intended fix for #283?
I also tried to add a shiny account and I got this error so I think that fix may have broken shiny.io deployments:
|
It looks like it is getting the API key from somewhere. Do you have CONNECT_API_KEY saved as an environment variable? |
Yes, that's what it was. I forgot I was testing that earlier. |
This might also be a bug, because a user may be intentionally adding a server with no API key but unwittingly use CONNECT_API_KEY set in their environment. |
FWIW, I haven't seen this documented anywhere and didn't know we used that variable for anything. |
The error message "RSConnectException: -n/--name cannot be specified in conjunction with options -s/--server" in vetiver #110 was just the symptom. 5ddd7ad fixes the underlying issue. -n and -s were mutually exclusive even in past versions, see here. |
When adding a Connect server I get this now:
Then when I create a
I think for most use-cases this is a little too much and would cause confusion. Can we put that info in the verbose logging instead? My first instinct if something isn't working as expected would be to add the verbose flag and then check the output there. Then we can elaborate a bit more too, something like:
|
'Add' is one of those commands that is use and forget but has huge number of downstream consequences. So showing the input detection at the initial step will prevent a lot of the environment variable issues our users encountered. |
We now allow adding a server without a
When you list the rsconnect servers it errors.
The server.json file looks like this:
The same command on 1.10.0 errors properly:
|
fixed by f8ea20e |
Description
1.10.0 added an erroneous exclusion that prevented users from using -n while also entering -k (or have CONNECT_API_KEY set in their environment variable). This PR fixes the exclusion. Now only -n and -s, and shinyapps options are mutually exclusive.
fixes #280
fixes connect #22150
fixes vetiver #110