This repository has been archived by the owner on Apr 17, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 5
Genericize Build Functionality #342
Comments
michaeltlombardi
added a commit
that referenced
this issue
Feb 11, 2022
Prior to this commit, the only implementation of an interface for the ConfigProcessor lived in the install package; moreover, this interface only included the ProcessConfig function. This commit creates a new public package, config_processor, which contains only a single interface: ConfigProcessorI. This interface includes both the ProcessConfig function and the new CheckConfig function. This will allow external libraries/tools to re-use our code so long as they implement a processor for their own needs which can perform those tasks. This commit does **not** implement or otherwise alter the private configuration processor (pct_config_processor) or any other files.
michaeltlombardi
added a commit
that referenced
this issue
Feb 11, 2022
Prior to this commit, functional logic for validating a config file lived not in the private processor (pct_config_processor) but in the private build package as a private function. This commit adds the CheckConfig function to the private processor as a public function so that the private processor becomes a valid implementation of the ConfigProcessorI interface. It slightly refactors the implementation from the build package in this transfer, as the logic for reading a configuration file is already defined in a private function for the private processor. It also ensures that the full path to the configuration file being checked is returned in any error messages; the prior implementation only specified 'pct-config.yml' which is neither generic for use in other libraries/tools, nor specific if the caller is pointing to a config anywhere but in the current working directory. This commit **does not** replace any upstream package usage to point to the new function, it **only** makes the private processor a valid implementation of the ConfigProcessorI interface.
michaeltlombardi
added a commit
that referenced
this issue
Feb 11, 2022
Prior to this commit, the private build package implemented its own private function to validate if a template config file prior to packaging it. This commit: 1. Updates the private build package to append a new value to its struct, ConfigProcessor, which must be a valid ConfigProcessorI interface. 2. Updates the private build package to replace calls to its own private checkConfig() function with calls to ConfigProcessor.CheckConfig. 3. Removes the private checkConfig() function from the private build package as it is no longer needed or used. 4. Updates the unit tests for the private build package to reflect the modified implementation of ConfigProcessor.CheckConfig() 5. Updates the build command itself to load the private processor.
michaeltlombardi
added a commit
that referenced
this issue
Feb 11, 2022
Prior to this commit, the install package created its own interface for ConfigProcessorI so that it could safely reference the ProcessConfig() function. This commit updates the install package to point instead to the ConfigProcessorI interface defined in the public config_processor package.
michaeltlombardi
added a commit
that referenced
this issue
Feb 12, 2022
Prior to this commit, functional logic for validating a config file lived not in the private processor (pct_config_processor) but in the private build package as a private function. This commit adds the CheckConfig function to the private processor as a public function so that the private processor becomes a valid implementation of the ConfigProcessorI interface. It slightly refactors the implementation from the build package in this transfer, as the logic for reading a configuration file is already defined in a private function for the private processor. It also ensures that the full path to the configuration file being checked is returned in any error messages; the prior implementation only specified 'pct-config.yml' which is neither generic for use in other libraries/tools, nor specific if the caller is pointing to a config anywhere but in the current working directory. This commit **does not** replace any upstream package usage to point to the new function, it **only** makes the private processor a valid implementation of the ConfigProcessorI interface.
michaeltlombardi
added a commit
that referenced
this issue
Feb 12, 2022
Prior to this commit, the private build package implemented its own private function to validate if a template config file prior to packaging it. This commit: 1. Updates the private build package to append a new value to its struct, ConfigProcessor, which must be a valid ConfigProcessorI interface. 2. Updates the private build package to replace calls to its own private checkConfig() function with calls to ConfigProcessor.CheckConfig. 3. Removes the private checkConfig() function from the private build package as it is no longer needed or used. 4. Updates the unit tests for the private build package to reflect the modified implementation of ConfigProcessor.CheckConfig() 5. Updates the build command itself to load the private processor.
michaeltlombardi
added a commit
that referenced
this issue
Feb 12, 2022
Prior to this commit, the install package created its own interface for ConfigProcessorI so that it could safely reference the ProcessConfig() function. This commit updates the install package to point instead to the ConfigProcessorI interface defined in the public config_processor package.
michaeltlombardi
added a commit
that referenced
this issue
Feb 14, 2022
Prior to this commit, the private build package contained several hard-coded references to pct-config.yml preventing this package from becoming truly generic. This commit removes the hard-coded config file name by extending the Builder struct to include the ConfigFile key for that value instead. This commit updates tests and the build command to reflect this refactor.
michaeltlombardi
added a commit
that referenced
this issue
Feb 14, 2022
Prior to this commit, the build package containing the Build() function for turning a config file with a content folder into an installable tar.gz was private, necessitating other libraries and tools to reimplement this logic. This commit takes the private build package and makes it public, now that it has no private package dependencies or hard-coded logic specific to PCT.
michaeltlombardi
added a commit
that referenced
this issue
Feb 14, 2022
Prior to this commit the `build.Build()` function took `templatePath` as the input for the directory to attempt to package and referenced the "template" in both comments and messages. This commit updates the function to instead take `sourceDir` as the input for the directory to attempt to package and removes all references to "template" from comments and messages, replacing it where coherent with "project" This further genericizes the build package for external library usage.
michaeltlombardi
added a commit
that referenced
this issue
Feb 14, 2022
Prior to this commit, the cobra `build` command used package variables and instantiated a PCT-specific `build` command in the `CreateCommand()` function. Any other cobra applications wanting to use the now-generic functionality from the public `build` package would need to reimplement this command wholly themselves as it hard-codes to PCT's packaging paradigm (i.e. it references "templates", expects a `pct-config.yml`, and instantiates the private PCT `ConfigProcessor`). This commit genericizes the `build` command by: 1. Replacing the package variables with a `BuildCommand` struct, declaring a `BuildCommandI` interface, and updating the functions (`CreateCommand()`, `preExecute()`, and `execute()`) to be attached to the new `BuildCommand` struct. 2. Replacing references in the `build` command's reference doc help text and error/info messaging, updating default language to "project" and extending the `BuildCommand` struct to include defining a `ProjectType` to clarify those docs/messages (i.e. "Builds a package from the template project" for PCT where `ProjectType` is set in the struct as `template`). 3. Moving the instantiation of the struct to `main` where it defines the `ProjectType` as `template` and instantiates the `build.Builder` struct, passing in the private `PctConfigProcessor`. During testing for this change, I noticed that the unit tests for the `build` command did not mock the `build.Builder`; this was because the `CreateCommand()` function instantiates that struct inside itself. Therefore, the unit tests were _actually_ trying to build packages. This commit reworks and simplifies those tests so that they use a new mock `Builder` instead of functionally (and without documentation) running integration tests for the `build` package.
michaeltlombardi
added a commit
that referenced
this issue
Feb 14, 2022
Prior to this commit, the cobra `build` command used package variables and instantiated a PCT-specific `build` command in the `CreateCommand()` function. Any other cobra applications wanting to use the now-generic functionality from the public `build` package would need to reimplement this command wholly themselves as it hard-codes to PCT's packaging paradigm (i.e. it references "templates", expects a `pct-config.yml`, and instantiates the private PCT `ConfigProcessor`). This commit genericizes the `build` command by: 1. Replacing the package variables with a `BuildCommand` struct, declaring a `BuildCommandI` interface, and updating the functions (`CreateCommand()`, `preExecute()`, and `execute()`) to be attached to the new `BuildCommand` struct. 2. Replacing references in the `build` command's reference doc help text and error/info messaging, updating default language to "project" and extending the `BuildCommand` struct to include defining a `ProjectType` to clarify those docs/messages (i.e. "Builds a package from the template project" for PCT where `ProjectType` is set in the struct as `template`). 3. Moving the instantiation of the struct to `main` where it defines the `ProjectType` as `template` and instantiates the `build.Builder` struct, passing in the private `PctConfigProcessor`. During testing for this change, I noticed that the unit tests for the `build` command did not mock the `build.Builder`; this was because the `CreateCommand()` function instantiates that struct inside itself. Therefore, the unit tests were _actually_ trying to build packages. This commit reworks and simplifies those tests so that they use a new mock `Builder` instead of functionally (and without documentation) running integration tests for the `build` package.
petergmurphy
added a commit
that referenced
this issue
Feb 14, 2022
(GH-342) Genericize Build functionality
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The functionality in PCT which enables a user to turn a template into a package should be genericized for reuse in PRM's tool building functionality.
The text was updated successfully, but these errors were encountered: