You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
What version of module-security should we use? (default: latest release (currently 'v0.1.0')):
The text was updated successfully, but these errors were encountered:
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:
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:
The text was updated successfully, but these errors were encountered: