At the present, all of the logic for building templates from this repository is tied to the repository itself. The current workflow for using this project is to clone this repository for your target, use one of the provided configuration to create a service branch, and then work on that when preparing your infrastructure. Although this does have the very large benefit of keeping target-specific building of templates together along with the history of the target, this workflow is contrary to how git should be used and violates the intentions of the project.
One of the bad sides with this present workflow is that each target repository that is forked from this project will also include all of the history of this project which results in each target repository being of an unnecessarily large size. Although having the user create a branch with a "magic" name (service) allows template building to incrementally developed, the semantics of git's branches and how they're intended to work is being violated.
Ideally, this project should be responsible for creating other projects for a given target, and then that way the projects aren't forcefully associated with the lolfuzz moniker. This would then separate the maintenance of lolfuzz from the maintenance of each target project. If a user wishes to re-synchronize their target with a later version of lolfuzz, then they may use lolfuzz to regenerate the rules for building each of the templates required by their target.
This PR takes the first step towards that reality by updating the rules for building the "master.project" template so that the templates can be deployed to an arbitrary directory on the filesystem. This distinctly separates the generated rules, keys, and states from lolfuzz and thus they can be worked on independantly without having to clone lolfuzz and make it part of the new project for a given target.
There's definitely a lot more that needs to be done to accomplish this goal.
At the present, all of the logic for building templates from this repository is tied to the repository itself. The current workflow for using this project is to clone this repository for your target, use one of the provided configuration to create a service branch, and then work on that when preparing your infrastructure. Although this does have the very large benefit of keeping target-specific building of templates together along with the history of the target, this workflow is contrary to how git should be used and violates the intentions of the project.
One of the bad sides with this present workflow is that each target repository that is forked from this project will also include all of the history of this project which results in each target repository being of an unnecessarily large size. Although having the user create a branch with a "magic" name (service) allows template building to incrementally developed, the semantics of git's branches and how they're intended to work is being violated.
Ideally, this project should be responsible for creating other projects for a given target, and then that way the projects aren't forcefully associated with the lolfuzz moniker. This would then separate the maintenance of lolfuzz from the maintenance of each target project. If a user wishes to re-synchronize their target with a later version of lolfuzz, then they may use lolfuzz to regenerate the rules for building each of the templates required by their target.
This PR takes the first step towards that reality by updating the rules for building the "master.project" template so that the templates can be deployed to an arbitrary directory on the filesystem. This distinctly separates the generated rules, keys, and states from lolfuzz and thus they can be worked on independantly without having to clone lolfuzz and make it part of the new project for a given target.
There's definitely a lot more that needs to be done to accomplish this goal.