Story #4082
Updated by amacdona@redhat.com almost 5 years ago
The plugin template has been very useful for creating new plugins. The downside is that since it is used only to create new plugins, it is not used frequently. The recent addition of generate_travis_config demonstrates that the template can also be useful for updating plugins, which will both increase usage and save plugin writers time. As we are expanding the usage, the following issues are arising: Problem 1: args instead of config. One pain point with generate_travis_config is that all the variables are set at runtime, so plugin writers need to remember the exact command used to generate their travis if they want to run it again to update those files. This concept will be a pain point for anything that the template is capable of updating. Problem 2: Multiple template types Some files are templated with string processing, some are templated with jinja Problem 3: Difficult to update plugins. Currently the template can only update travis files because bootstrap will clobber their existing work. h3. HIgh Level Plan The changes will all be implemented in sub-tasks to this epic issue. *all jinja* Replace all string formatting with jinja templates. *committed config values*: A yml file (checked into git) will be used to store human readable values, allowing repeated, idempotent usage. *New CLI:* `plugin-template init [path/to/plugin/parentdir/, defaults to ../]`: * Wizard asks user for any config values necessary to bootstrap the template. * Create a root directory for new plugin * creates a user-editable template-config.yml file in the plugin root dir that stores all the config values (all values commented in the file) `plugin-template bootstrap <path-to-plugin-rootdir>`: * Reads the template file at <path>/template-config.yml * render files conditionally based on yml. (ie, if deploy-pypi-client is set to false, don't template that file) `plugin-template update <path-to-plugin-rootdir> [--file-path <path>] * Reads the template file at <path>/template.yml * similar to bootstrap command, but act only on "managed files" which are files which should not be updated manually by the plugin author, ex .travis/script.sh * if --file-path <path> is passed, render that file only. this can be used to deliberately clobber files that need updating, but are not "managed files", giving the plugin author granular control. Note: All changes should be made against the filesystem only, and should not invoke git. The plugin writer can then use `git diff` to make sure that the changes are correct for their plugin, and gives them the option to not stage certain changes. Story 1: Begin a new CLI by refactoring `bootstrap` to use jinja templates. Bootstrap will create a new plugin from scratch and populate all the files. Story 2: Add `init` command: Creates a root directory for the new plugin and places a yaml file in it. The yaml file is populated with all variables necessary to run `bootstrap`. Story 3: Add `update` command: Update "managed" files only. Files that should not be updated by plugin writers are called "managed files". The base list of these files will be determined by the options in the yaml file. ie, `publish_client_gem.sh` might be left out based ont th
.