Open josh-padnick opened 7 years ago
The trickiest question is how to handle this in a generic way that would make sense as part of boilerplate core. Looking up GitHub release data, especially for private repos, can get pretty damn messy...
That's a good point. I think a "plugin" architecture that cleanly separates the complexity of github release lookups from boilerplate core is the only way. For example, here's how Vault handles different auth backends:
https://github.com/hashicorp/vault/tree/6beadc1e1c9c7d317ef8074eaa3f26dfcc936f4d/builtin/credential
I'm pretty sure they all implement some common interface. In our case, we could have a plugin concept for "ways of computing a default", define an interface, and then write whatever plugins we want. To get the latest release from GitHub, we could copy a bunch of code from fetch.
Many of my boilerplate variables are just a asking what GitHub release / git tag I want from a given repo. The default is the latest version at the time the author wrote the
boilerplate.yml
file so I can never trust that it is in fact the latest.Therefore, it'd be nice if I could specify some kind of
github-latest-release
plugin in boilerplate that would compute my default value instead of just using a default literal.Example: