-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
env config settings is displayed correctly #5879
Conversation
Previously was being dropped as the value of `env` was slightly different from the rest of the resolved config. It did not have an explicit `from`/`value` combo. NormalizeWithoutMeta strips `from`/`value` to simply the value. This is not explictly done for the env key's values.
Thanks for the contribution! Below are some guidelines Cypress uses when doing PR reviews.
PR Review ChecklistIf any of the following requirements can't be met, leave a comment in the review selecting 'Request changes', otherwise 'Approve'. User Experience
Functionality
Maintainability
Quality
Internal
|
Test summaryRun details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
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.
Manually tested, looks good - also nests the env vars. 👍 I did not have time to review the code.
Also, just as a note @andrew-codes, in the section for 'How has the user experience changed' it's nice to have a before/after screenshot (after like the one below) demonstrating the fix versus the undefined
value before. It's quicker than having to go look at the issue or read all the text explaining.
Let me pull a screenshot of before and after. Thank you for the feedback @jennifer-shehane |
Good catch @chrisbreiding. Let me add a test and resolve the issue when there is no env value. |
it('displays env settings', () => { | ||
cy.get('@config').then(({ resolved }) => { | ||
const getEnvKeys = flow([ | ||
get('env'), | ||
toPairs, | ||
map(([key]) => key), | ||
sortBy(get('')), | ||
]) | ||
|
||
cy.contains('.line', 'env').contains(flow([getEnvKeys, join(', ')])(resolved)) | ||
cy.contains('.line', 'env').click() | ||
const assertKeyExists = each((key) => cy.contains('.line', key)) | ||
const assertKeyValuesExists = flow([ | ||
map((key) => { | ||
return flow([ | ||
get(['env', key, 'value']), | ||
(v) => { | ||
if (isString(v)) { | ||
return `"${v}"` | ||
} | ||
|
||
return v | ||
}, | ||
])(resolved) | ||
}), | ||
each((v) => { | ||
cy.contains('.key-value-pair-value', v) | ||
}), | ||
]) | ||
|
||
const assertFromTooltipsExist = flow([ | ||
map((key) => { | ||
return [key, | ||
flow([ | ||
get(['env', key, 'from']), | ||
(from) => `.${from}`, | ||
])(resolved)] | ||
}), | ||
each(([key, fromTooltipClassName]) => { | ||
cy.contains(key).parents('.line').first().find(fromTooltipClassName) | ||
}), | ||
]) | ||
|
||
flow([getEnvKeys, assertKeyExists])(resolved) | ||
flow([getEnvKeys, assertKeyValuesExists])(resolved) | ||
flow([getEnvKeys, assertFromTooltipsExist])(resolved) | ||
}) | ||
}) |
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.
this looks pretty gnarly, and i think you could use some cypress-isms to clean this up. come find me and i can show you some tricks
cy.contains('.line', 'env').contains(flow([getEnvKeys, join(', ')])(resolved)) | ||
cy.contains('.line', 'env').click() |
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.
these lines should go below the const ... =
assignments because the execute async.
It's generally better to group the sync/async code together
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.
I left a few comments and since I don't see the test for handling when env
is undefined
I assume you still need to commit something...
So I'll Request Changes in the mean time so you can address the other feedback.
this.ipc.openProject.onCall(1).resolves(setConfigEnv(this.config, null)) | ||
this.ipc.onConfigChanged.yield() | ||
|
||
cy.contains('.line', 'env:null') | ||
|
||
this.ipc.openProject.onCall(2).resolves(setConfigEnv(this.config, {})) | ||
this.ipc.onConfigChanged.yield() | ||
|
||
cy.contains('.line', 'env:null') | ||
|
||
this.ipc.openProject.onCall(3).resolves(setConfigEnv(this.config, undefined)) | ||
this.ipc.onConfigChanged.yield() | ||
|
||
cy.contains('.line', 'env:null') |
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.
i don't believe you're coordinating the stubs + the cypress commands correctly here because the cypress commands are async and the this.ipc.onConfigChanged.yield()
is synchronous. I believe it's synchronously firing the onConfigChanged
immediately (three times), and so the final undefined
value is being flushed to the DOM, and then the three cy.contains(...)
are running only against the last render of the DOM (which is undefined
).
To fix this you need to use a .then()
so that the IPC events are fired after the cy.contains()
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.
Thanks for pointing this out and going over it with me. Consequently, the implementation passes for each use case, null
, undefined
, and {}
. However, even with the new code changes to the test that we worked on, I get strange behavior. I broke them into 3 separate E2E test cases, but I don't much like it. I'd love it if anyone has any insights on how to combine them into a single test case.
implementation works individually for each of the three test cases. I don't like breaking them into three separate E2E tests, but I'm unsure how to orchestrate them properly otherwise.
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.
approving assuming we get the tests cleaned up a bit and passing
- only a single test; no longer 3 separate tests for the same case
Released in |
env
variables asundefined
#5859User facing changelog
env
configuration option displays properly within the settings panel. Previously, setting env options would incorrectly render"undefined"
as the value.Additional details
The resolved config has metadata around where the value comes from. For example,
blacklistHosts
's value is an object with afrom
andvalue
key. The component rendering the config accepts a normal object, so we do not want to include this additional metadata. Prior to passing it along, the resolved config is normalized without the metadata. However, theenv
value turned out to be a special case; with its value being the actual value instead of afrom
andvalue
object. Due to this, the process of normalizing the resolved config stripped this out entirely; leaving an undefined value.Now, the resolved config is processed to strip metadata and then the
env
key is explicitly added back.Tests were also added to ensure the existence of env data is rendered properly; both initially, expanded, and with the correct tooltip information.
How has the user experience changed?
Before Screenshot
After Screenshot
PR Tasks