Skip to content

Conversation

@hetangmodi-crest
Copy link
Contributor

@hetangmodi-crest hetangmodi-crest commented Mar 7, 2025

Issue number:
ADDON-78488

PR Type

What kind of change does this PR introduce?

  • Feature
  • Bug Fix
  • Refactoring (no functional or API changes)
  • Documentation Update
  • Maintenance (dependency updates, CI, etc.)

Summary

Generate minimal globalConfig.json when there is no globalConfig in source code.

Changes

If any TA doesn't have globalConfig.json in its source directory, then after building add-on we will be generating minimal globalConfig.
We are generating this minimal globalConfig using data present in app.manifest and app.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.

@hetangmodi-crest hetangmodi-crest added the enhancement New feature or request label Mar 7, 2025
@hetangmodi-crest hetangmodi-crest self-assigned this Mar 7, 2025
@hetangmodi-crest hetangmodi-crest marked this pull request as ready for review March 10, 2025 13:10
@hetangmodi-crest hetangmodi-crest requested review from a team as code owners March 10, 2025 13:10
@artemrys artemrys changed the title feat : create minimal global config using app.manifest and app.conf feat: create minimal global config using app.manifest and app.conf Mar 12, 2025
from ..file_generator import FileGenerator


class GlobalConfigGenerator(FileGenerator):
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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.

return "test_addon"


@patch("addonfactory_splunk_conf_parser_lib.TABConfigParser")
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

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.

@@ -0,0 +1,12 @@
def test___init__html():
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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):
Copy link
Member

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.

Copy link
Contributor Author

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).

Copy link
Member

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.

Copy link
Contributor Author

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(
Copy link
Member

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.

Copy link
Member

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.

@github-actions
Copy link

Code Coverage 🎉

Type PR Develop Change Status
Line Coverage 87.04% 86.90% 0.14% 🟢 Increased
Branch Coverage 80.41% 80.12% 0.29% 🟢 Increased

if self._is_global_config_yaml
else json.loads(config_raw)
)
def __init__(self, global_config_path: str, **kwargs: Any) -> None:
Copy link
Member

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:
Copy link
Member

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".

Copy link
Member

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.

@hetangmodi-crest
Copy link
Contributor Author

Closing the PR as I'll raise a new PR once PR #1655 is merged.

@github-actions github-actions bot locked and limited conversation to collaborators Mar 26, 2025
@hetangmodi-crest
Copy link
Contributor Author

Raised the PR #1669 to cover the changes.

@hetangmodi-crest hetangmodi-crest deleted the feat/create-minimal-globalConfig branch March 31, 2025 07:20
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

enhancement New feature or request size/XL

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants