-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
grains: Split os_data into smaller functions #61597
Conversation
bd7eea1
to
3711114
Compare
1f9d621
to
61b9d1e
Compare
Rebased and added two more commits. |
615eaee
to
75fcf63
Compare
75fcf63
to
a98dbe8
Compare
a98dbe8
to
9d278d6
Compare
Rebased and added a test case for |
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.
9d278d6
to
a4fcc05
Compare
The `os_data` function is huge (531 lines for one function is too long) and also deeply nested (8 levels deep). That make reading, modifying, and testing this function harder. Split `os_data` into smaller functions to a readable 167 lines with only a nesting level of three. Signed-off-by: Benjamin Drung <[email protected]>
`os_data` has a case-like statement to differentiate the different operating systems, but this is split into two parts. To make the code more readable, combine all case-like statement in `os_data` to use one long if-elif chain. Signed-off-by: Benjamin Drung <[email protected]>
Move fetching `lsb_distrib_*` grains into separate function `_linux_lsb_distrib_data` to make `_linux_distribution_data` shorter. Signed-off-by: Benjamin Drung <[email protected]>
To make the code easier to read, set `os_family` in each branch in `os_data()`. Most branches have an hard-coded OS family and can be dropped from `_OS_FAMILY_MAP`. The dictionary `_OS_FAMILY_MAP` is now only used for deriving the OS family of Linux. Signed-off-by: Benjamin Drung <[email protected]>
In `os_data()` only the kernel branch for `SunOS` might not set the `os` grain. To make the code easier to read, ensure that `os` is set in each branch in `os_data()`. Signed-off-by: Benjamin Drung <[email protected]>
The test cases for `os_data` do not cover the case that `lsb_release` is imported successfully. So add a test case for that. Signed-off-by: Benjamin Drung <[email protected]>
a4fcc05
to
5344c7b
Compare
@dmurphy18 #61626 is the final merge request containing all changes. Since that merge request is big, I split it into multiple smaller chunks (that stack on each other). This merge request is the first one. I rebased it on master and resolved the conflict. |
Forgot still needs a changelog entry
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.
Sorry forgot this will still need a changelog entry before can approve and merge.
Retrying failing tests - passed, but changes looks good.
Why does this pull request need a changelog entry? It does not change anything for the user. Only #61626 has user facing changes and changelog entries. |
@bdrung Sorry, so used to everything needing a changelog. You are correct, if it did not impact user and was only internal things it does not add a changelog, approving this |
Thanks. The next pull request in this series is #61589 |
The
os_data
function is huge (531 lines for one function is too long) and also deeply nested (8 levels deep). That make reading, modifying, and testing this function harder.Split
os_data
into smaller functions to a readable 167 lines with only a nesting level of three.os_data
has a case-like statement to differentiate the different operating systems, but this is split into two parts.To make the code more readable, combine all case-like statement in
os_data
to use one long if-elif chain.