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
Move install logic out of private config processor and into install #349
Labels
enhancement
New feature or request
Comments
petergmurphy
pushed a commit
that referenced
this issue
Feb 16, 2022
Prior to this commit, the private processor included the ProcessConfig public function which called the private functions readConfig and setupTemplateNamespace to place a package in the right folder structure so that it is recognized as an installed package. This is an install function placed in the config processor. This commit replaces the ProcessConfig function in the config_processor.ConfigProcessorI interface with GetConfigMetadata, which returns the new ConfigMetadata struct also newly defined in config_processor. This enables a consumer of a ConfigProcessorI implementation to retrieve the metadata needed to install a package generically. The prior implementation conflated configuration processing with install logic. This commit adds a new public function to the install package, InstallFromConfig. This function combines the logic from the removed ProcessConfig and setupTemplateNamespace functions from the private config processor, genericising it in the process. This commit extends the install.Installer struct to take a config file name, so that no hard coding of the config file name is needed in the package; this makes it generically reusable regardless of config file.
petergmurphy
pushed a commit
that referenced
this issue
Feb 18, 2022
petergmurphy
pushed a commit
that referenced
this issue
Feb 18, 2022
In this commit, update unit tests have been added for the newly refactored `pkg/install/install.go`. The `install_config.go` mock file for mocking the private config processor has been updated, implementing the new config processor interface.
petergmurphy
pushed a commit
that referenced
this issue
Feb 18, 2022
In this commit, update unit tests have been added for the newly refactored `pkg/install/install.go`. The `install_config.go` mock file for mocking the private config processor has been updated, implementing the new config processor interface.
petergmurphy
pushed a commit
that referenced
this issue
Feb 18, 2022
petergmurphy
pushed a commit
that referenced
this issue
Feb 18, 2022
In this commit, update unit tests have been added for the newly refactored `pkg/install/install.go`. The `install_config.go` mock file for mocking the private config processor has been updated, implementing the new config processor interface.
petergmurphy
pushed a commit
that referenced
this issue
Feb 18, 2022
In this commit, update unit tests have been added for the newly refactored `pkg/install/install.go`. The `install_config.go` mock file for mocking the private config processor has been updated, implementing the new config processor interface.
petergmurphy
pushed a commit
that referenced
this issue
Feb 18, 2022
In this commit, update unit tests have been added for the newly refactored `pkg/install/install.go`. The `install_config.go` mock file for mocking the private config processor has been updated, implementing the new config processor interface.
petergmurphy
pushed a commit
that referenced
this issue
Feb 18, 2022
Prior to this commit, the private processor included the ProcessConfig public function which called the private functions readConfig and setupTemplateNamespace to place a package in the right folder structure so that it is recognized as an installed package. This is an install function placed in the config processor. This commit replaces the ProcessConfig function in the config_processor.ConfigProcessorI interface with GetConfigMetadata, which returns the new ConfigMetadata struct also newly defined in config_processor. This enables a consumer of a ConfigProcessorI implementation to retrieve the metadata needed to install a package generically. The prior implementation conflated configuration processing with install logic. This commit adds a new public function to the install package, InstallFromConfig. This function combines the logic from the removed ProcessConfig and setupTemplateNamespace functions from the private config processor, genericising it in the process. This commit extends the install.Installer struct to take a config file name, so that no hard coding of the config file name is needed in the package; this makes it generically reusable regardless of config file.
petergmurphy
pushed a commit
that referenced
this issue
Feb 18, 2022
petergmurphy
pushed a commit
that referenced
this issue
Feb 18, 2022
In this commit, update unit tests have been added for the newly refactored `pkg/install/install.go`. The `install_config.go` mock file for mocking the private config processor has been updated, implementing the new config processor interface.
michaeltlombardi
pushed a commit
that referenced
this issue
Feb 18, 2022
Prior to this commit, the private processor included the ProcessConfig public function which called the private functions readConfig and setupTemplateNamespace to place a package in the right folder structure so that it is recognized as an installed package. This is an install function placed in the config processor. This commit replaces the ProcessConfig function in the config_processor.ConfigProcessorI interface with GetConfigMetadata, which returns the new ConfigMetadata struct also newly defined in config_processor. This enables a consumer of a ConfigProcessorI implementation to retrieve the metadata needed to install a package generically. The prior implementation conflated configuration processing with install logic. This commit adds a new public function to the install package, InstallFromConfig. This function combines the logic from the removed ProcessConfig and setupTemplateNamespace functions from the private config processor, genericising it in the process. This commit extends the install.Installer struct to take a config file name, so that no hard coding of the config file name is needed in the package; this makes it generically reusable regardless of config file. Additionally, this bug corrects a minor issue in the cleanup for an installed package, ensuring the temp folder the package is gunzipped to can actually be deleted on Windows by replacing the `AFS.Remove()` call with one to `AFS.RemoveAll()`, which removes a folder and its children recursively. `AFS.Remove()` previously errored on Windows due to the gunzipped tar file remaining after the untarred contents were moved.
michaeltlombardi
pushed a commit
that referenced
this issue
Feb 18, 2022
michaeltlombardi
pushed a commit
that referenced
this issue
Feb 18, 2022
In this commit, update unit tests have been added for the newly refactored `pkg/install/install.go`. The `install_config.go` mock file for mocking the private config processor has been updated, implementing the new config processor interface.
petergmurphy
pushed a commit
that referenced
this issue
Mar 4, 2022
petergmurphy
pushed a commit
that referenced
this issue
Mar 4, 2022
In this commit, update unit tests have been added for the newly refactored `pkg/install/install.go`. The `install_config.go` mock file for mocking the private config processor has been updated, implementing the new config processor interface.
chelnak
added a commit
that referenced
this issue
Apr 9, 2022
(GH-349) Genericize `install` package logic and move it from the private config processor into the package
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The
ConfigProcessorI
interface requires a valid interface to have two functions:CheckConfig()
andProcessConfig()
. On inspection,ProcessConfig()
is an install-only function which uses data returned from the currently privatereadConfig()
function to determine behavior.This functionality actually belongs in the
install
package as the function has to do with how a package is installed, not how a config is parsed/validated/read.Acceptance Criteria
ConfigProcessorI
is updated to haveReadConfig()
as a required functionreadConfig()
into a public function in the private config processor - work needs to be done to make the info returned byReadConfig()
a generic struct that can be shared; right now PCT requires thePuppetContentTemplateInfo
struct and PRM requires theToolConfigInfo
struct - these are functionally identical, save for the PCT implementation looking for thetemplate
key and PRM theplugin
key. Two options: first, update the keys for both to match (say, replacingtemplate
andplugin
withmeta
- quick look at bothpct-config.yml
andprm-config.yml
files shows that the data in these sections is about the package itself - it's id/author/type/display name/version/url/etc. The struct only cares about the top level key as other methods are used to retrieve the rest of the information; the second option is to figure out a way to handle expecting a generic object which could be either extant struct. Possibly useful is this blog on forcing a dynamic typeProcessConfig()
andsetupTemplateNamespace()
into theinstall
package as either a private or public functionsProcessConfig()
from theConfigProcessorI
interfaceThe text was updated successfully, but these errors were encountered: