Plan for updating projects when templates change?

[sgoings]

I'm currently toying around with the makeup project and would love to see the makeup cli be fully ported to the boilr tool. However, I'm held up by what boilr's offerings for a "template update" feature might be.

Creating a project for the first time is a fairly automateable and understandable task, but having the ability to take a project from an initial creation and slowly add in advancements/features down the line is a trickier endeavor (think: when the templates add awesome functionality and people want that new functionality...). Have you thought about how you might accomplish this?

A common use case of boilr for me starts with the initial bootstrapping:

• create a repository (named: repoA) that runs boilr template type: makeup with version: 1
  • this boilr template would inject a few fancy includeable makefiles into the project
• finally, I'd ask the user to place the include script logic into the makefile in order to reap the benefits of the nice makefile targets that the boilr template just gave them

Somewhere down the road, I'm going to want to use boilr to move the repoA project from version 1 to version 2 (after adding some more makefile targets).

I have a few possible directions:

• have the template creator be in charge of providing upgrade scripts within the template "plugin" that people use... such that people could initiate: boilr upgrade license <project> and that would:
  • identify the version of the template that the current license was created by
  • identify which "upgrade script" to use to upgrade the resultant file (from template) to the latest resultant file (from latest template)
• have an "upgradeable" template type where people can't modify the results of the boilr creation, but they're "injected/imported" into their project somehow (this is makeup's strategy). This is similar to the above strategy but also encourages people will have less surface area to worry about mucking up existing projects.
  • upgrades turn into just simple replacements of the original resultant file with the output of a new processed template
  • the leftover minimal surface area could possibly be delegated to the user in some fashon. (see: brew info or kubectl edit type workflows).
• do nothing (don't handle this case) :smile:

[tmrts]

Thank you for your detailed use case and feature request.

We can assume that any successful template will have new features and bug fixes. But, I didn't consider updating used templates when the boilr templates are updated since the aim at the moment is to provide a starter boilerplate for users.

However, I can see the benefit of adding a mechanism as a plugin command (boilr plugin X args) with some modifications.

I think using upgrade might be confusing to people since templates are saved locally and they might think it is for updating stored templates. Instead migrate might be a better name for this context.

In order to allow people to upgrade their used templates, the used template needs to be parsed but I'm not sure if that's the way to go. Instead, boilr can store the answers given to that particular template and then when asked boilr plugin migrate <path>, it can automatically use the same answers, but it might overwrite the changes so users either, need to be warned about this or as you suggested a read-only template mechanism can be implemented (e.g. boilr use --read-only <template-name> <target-dir>)

Cons of automatically using the answers:

• Needs execution records, if the template is used on machine A, can't be migrated on machine B

Cons of read-only templates:

• Introduces even more complexity from the users point of view since they need to know about doing read-only templates and then using the plugin. Instead a composed single command is better.

[sgoings]

I like this idea:

boilr can store the answers given to that particular template and then when asked boilr plugin migrate <path>

Where they'd potentially be asked more questions if the newer version needed to. I'm totally ok with this feature starting out as a plugin. That's what we did with helm.

[jdoklovic]

Personally, I think updating can be even simpler to begin with if a template could simply identify which files can be overwritten.

e.g. I create a project with boilr that creates a readme and a CI plan template. Then I add a bunch of code and update the readme. Then at some point the completely boilerplate CI template is updated. I should be able to run some sort of update that keeps all of my newly created files, does not overwrite the readme, but does overwrite the CI template.

[tmrts]

@jdoklovic since we have started using git as the back-end, implementation of this feature is simplified considerably.

What we want is basically a git-rebase:

1. User renders the template
2. User does some other modifications
3. Updated template is downloaded
4. A stash and rebase is performed on the previously executed & used template

There are some problems with this solution, such as rebase conflicts