-
Notifications
You must be signed in to change notification settings - Fork 35
feat: create minimal global config using app.manifest and app.conf #1625
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
Conversation
| from ..file_generator import FileGenerator | ||
|
|
||
|
|
||
| class GlobalConfigGenerator(FileGenerator): |
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.
Can MinimalGlobalConfig inherit FileGenerator directly without this middleware?
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 did think about it, but didn't proceed with it as I thought we might move the ucc-gen init command to generate globalConfig with this hierarchy, just to keep everything in same umbrella.
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 think we can make it much simpler but inheriting directly, this way we can avoid having tests/unit/generators/globalConfig_generator/test_globalConfig_generator.py at all.
We can always refactor it later if we need to bring in another feature.
tests/unit/generators/globalConfig_generator/test_create_minimal_globalConfig.py
Outdated
Show resolved
Hide resolved
| return "test_addon" | ||
|
|
||
|
|
||
| @patch("addonfactory_splunk_conf_parser_lib.TABConfigParser") |
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.
Why are we patching TABConfigParser?
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.
Since _set_attributes utilizes TABConfigParser to read app.conf and we do not have an actual app.conf, I have mocked it this.
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 test case tests the internal implementation.
I'd like to see the complete unit test for this functionality. If we need app.manifest and app.conf files for this to work, I'd like to see the following test:
app_conf = AppConf("...")
app_manifest = AppManifest("...")
minimal_global_config = MinimalGlobalConfig(
...,
app_conf,
app_manifest,
)
If we can't write a test like this right now - we need to refactor our code urgently.
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 with the test_generate_minimal_gc test case in this file. I would like to see the test verifying the result after running the code rather than verifying how many time something was called.
tests/unit/generators/globalConfig_generator/test_globalConfig_generator.py
Outdated
Show resolved
Hide resolved
| @@ -0,0 +1,12 @@ | |||
| def test___init__html(): | |||
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.
What is the purpose of this test?
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.
To ensure that only expected classes and modules exist in globalConfig_generator
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.
Those modules and classes are internal, I do not expect them to be used by some other program from the outside world so I do not see a lot of value in keeping those tests.
| import addonfactory_splunk_conf_parser_lib as conf_parser | ||
|
|
||
|
|
||
| class MinimalGlobalConfig(GlobalConfigGenerator): |
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.
Hm, would it make sense for this logic to be part of an existing globalConfig? This breaks the whole integration with ...Generator classes but it would be consistent with the existing class.
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 idea was, since we are generating globalConfig, I kept it under ...Generator class. Moreover, if we move it to GlobalConfig class of global_config.py, we would be updating the behaviour of that class - currently, it is to parse a globalConfig and convert it to a dictionary and provide properties to access various attributes. Moving this implementation there, this class would be responsible to create a physical globalConfig file (if not present) and then continue with the current behaviour. Additionally, we would require to give the source_dir path (which induces additional changes in the tests).
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 see 2 benefits of having a class MinimalGlobalConfig inherit FileGenerator.
First - we will get our documentation page updated automatically. Second - we could eventually compare generated files by us and what's in the package.
First benefit is nice to have but totally optional. Second one is absolutely great but is not applicable to the globalConfig itself.
I would imaging GlobalConfig to have a classmethod from_app_conf_and_app_manifest (the name is not the best, I agree), accept an instance of app.conf and app.manifest files as classes and produce a GlobalConfig class as a result which can be written somewhere later.
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.
Migrated the implementation from Filegenerator to GlobalConfig class.
| self._original_path = global_config_path | ||
| self.user_defined_handlers = UserDefinedRestHandlers() | ||
|
|
||
| def generate_minimal_globalconfig( |
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 was thinking more about something like in this PR - #1655. We introduce the second way to initialize the GlobalConfig class which takes an instance of AppConf and an instance of AppManifest classes and should return GlobalConfig as a result. We do not need to dump it straight in this method, we have dump method in the GlobalConfig class which is designed to do it.
We might need another refactor PR to handle the _original_path parameter in the GlobalConfig class.
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.
Let's introduce this new from_app_conf_and_app_manifest method in a separate PR, you might need to make _original_path to be Optional[str] which may cause other parts of the class to be refactored.
Code Coverage 🎉
|
| if self._is_global_config_yaml | ||
| else json.loads(config_raw) | ||
| ) | ||
| def __init__(self, global_config_path: str, **kwargs: Any) -> None: |
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.
@hetangmodi-crest this conflicts with https://github.com/splunk/addonfactory-ucc-generator/pull/1655/files, please review that PR first and let's merge it.
I'd like to keep the __init__ method how it is in that PR.
| source_dir: str, | ||
| app_manifest: app_manifest_lib.AppManifest, | ||
| app_conf_content: Dict[str, Any], | ||
| ) -> str: |
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.
It should be a classmethod and it should return "GlobalConfig".
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 please make it a separate PR after #1655 is merged.
|
Closing the PR as I'll raise a new PR once PR #1655 is merged. |
|
Raised the PR #1669 to cover the changes. |
Issue number:
ADDON-78488
PR Type
What kind of change does this PR introduce?
Summary
Generate minimal
globalConfig.jsonwhen there is noglobalConfigin source code.Changes
If any TA doesn't have
globalConfig.jsonin its source directory, then after building add-on we will be generating minimalglobalConfig.We are generating this minimal globalConfig using data present in
app.manifestandapp.conf.Achieved 100% unit test case coverage for this PR.
User experience
After this, every TA will have globalConfig in their source code.
Checklist
If an item doesn't apply to your changes, leave it unchecked.