♻️ Rename server address method / environment variable #256
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wwilsman
force-pushed
the
ww/cors-exposed-headers
branch
from
834f6a5 to
68b99b9
Compare
wwilsman
force-pushed
the
ww/rename-server-addr-vars
branch
from
65c843a to
bc5f45b
Compare
Robdel12
approved these changes
Mar 22, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose
Initially, the
PERCY_CLI_APIenvironment variable was named so because it was the CLI that set that variable for SDKs to consume. However, that API address can still be consumed by SDKs without the CLI. In reality, this value comes from the core server, so it's name should reflect that.PERCY_SERVER_ADDRESSwas chosen as it is pretty descriptive in that the variable contains the address of the local Percy server. However, I'm open to other suggestions.Since this variable is only set by the CLI, and official SDKs consume this internally, I wouldn't count this as breaking for our own SDKs. If the user was using the
--portoption (not likely), it will still continue to work once the SDK is updated to account for the new variable name. However this would be considered a breaking change for custom SDKs that do not use sdk-utils, although this package is technically still beta so changes should be expected.Depends on #252, #253, #254, & #255