-
Notifications
You must be signed in to change notification settings - Fork 296
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
Finish reading deployment profiles from the Windows registry #4251
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.
This PR is missing tests. Actually, we should have tests in a separate PR, and merge that before this one.
a97fdca
to
1691e41
Compare
7bca028
to
d2f8831
Compare
16cb99e
to
f634529
Compare
53c0ac5
to
ea0a4f1
Compare
0133e77
to
27bb153
Compare
23a2b17
to
ab9f223
Compare
27bb153
to
2ee51de
Compare
67dd43a
to
72e6f2e
Compare
ab9f223
to
a6c769d
Compare
bcdfafc
to
0f42874
Compare
1e97704
to
03bc6a0
Compare
03bc6a0
to
9c0c48a
Compare
3a79099
to
2e11979
Compare
2e11979
to
fe879d4
Compare
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.
Unflagging for review because this keeps being changed
0c6faec
to
a9bba89
Compare
Keep in mind that the follow-up PR #4612 will display deployment profile type-errors in a dialog box and then shut down. This PR is about doing a better job of reading deployment profiles, and it also recognizes the "special objects", like |
registryKeysFixedCase.forEach((key, index) => { | ||
const originalKey = registryKeys[index]; |
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.
We don't seem to ever need index
again, and registryKeysFixedCase
is only used here.
I think the code would be a lot easier to understand as:
registryKeysFixedCase.forEach((key, index) => { | |
const originalKey = registryKeys[index]; | |
for (const originalKey of Object.keys(schemaObj)) { | |
const key = fixProfileKeyCase(originalKey, schemaKeys); |
Looking at the loop over commonKeys
, it's probably better to call these schemaKey
and registryKey
, too.
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.
With this approach, you're not going to find keys that are in the registry instance but aren't in the schema.
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.
In that case, how about:
for (const originalKey of nativeReg.enumKeyNames(regKey)) {
const key = fixProfileKeyCase(originalKey, schemaKeys);
(You'll notice that my original code is wrong anyway, passing a key of schemaObj
to fixProfileKeyCase
doesn't make sense…)
const registryValueNames = nativeReg.enumValueNames(regKey); | ||
const registryValueNamesFixedCase = registryValueNames.map(k => fixProfileKeyCase(k, schemaKeys)); | ||
|
||
registryValueNamesFixedCase.forEach((key, index) => { |
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.
Same as above — for (const originalName of nativeReg.enumValueNames(regKey) { const key = fixProfileKeyCase(originalName, schemaKeys);
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.
And same as above, if we walk the schema instead of the registry we miss undefined entries
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.
Ah! My suggestion here was correct (enumerating over the result of enumValueNames
).
4b25702
to
2f50bbc
Compare
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.
A lot of this type checking makes me think we should just pull in the schema validator we already use for the HTTP API. We may need to massage it to be usable here, though. Also, that can be a follow-up PR.
c7f0b22
to
d8b9be9
Compare
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.
Nothing major left, just some nits. The main changes are just in the test.
// Drop the initial 'defaults' or 'locked' field | ||
const pathPartsWithoutHiveType = pathParts.slice(1); | ||
|
||
for (const originalKey of nativeReg.enumKeyNames(regKey)) { |
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.
for (const originalKey of nativeReg.enumKeyNames(regKey)) { | |
for (const registryKey of nativeReg.enumKeyNames(regKey)) { |
Since that makes it easier when we push to userDefinedObjectKeys
/commonKeys
.
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.
Good catch
8d35f55
to
cbfd7bf
Compare
- Don't complain about any entries in the settings schema that aren't in the registry. - Treat `WSL/integrations`, `extensions`, and `diagnostics/mutedChecks` as hashes - Registry keys and value names are case-insensitive - Do type-based parsing of raw registry values. - There's no need to do post-input validation of registry data. The reader validates as it goes. - Convert 0s and 1s in user-defined objects into booleans. Currently if there are certain errors in a deployment profile, such as unrecognized names or type mismatches, we log them but they aren't fatal, and aren't shown in a dialog box. These will be raised into dialog boxes with fatal errors in a subsequent PR. Signed-off-by: Eric Promislow <[email protected]>
- Use case-sensitive checks for user-defined objects. We've already normalized the case of the registry field, so can use === to compare. - The reg file can be ascii-encoded. Any non-ascii characters should appear only inside SZ strings and be hex-encoded. All the names in the schema can be represented in 7-bit ASCII characters so there's no need to support other encodings. Signed-off-by: Eric Promislow <[email protected]>
cbfd7bf
to
cf06fdc
Compare
Signed-off-by: Eric Promislow <[email protected]>
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.
While I have a couple comments, they don't block merging.
await fs.promises.rm(testDir, { force: true, recursive: true }); | ||
consoleMock.mockReset(); | ||
}); | ||
// TODO: Add an `afterAll(clearRegistry)` when we're finished developing. |
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.
Does that mean we should do it before the PR merges?
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.
No, there are still at least two more PRs to come after this one.
|
||
return false; | ||
function haveUserDefinedObject(pathParts: string[]): boolean { | ||
return userDefinedKeys.some(userDefinedKey => _.isEqual(userDefinedKey, pathParts)); |
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.
The non-lodash way would be
const userDefinedKeys = ['extensions', 'WSL.integrations', 'diagnostics.mutedChecks'];
function haveUserDefinedObject(pathParts: string[]): boolean {
return userDefinedKeys.includes(pathParts.join('.'));
}
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.
But then you're always joining an array to create a string, and I'm going to assume lodash's way of doing the comparison will be faster, since it will eliminate different-size arrays and fail on the different in the first string right away.
The diff is probably miniscule in the scheme of things anyway.
Fixes #4153
Fixes #4193