-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow loading choices from API call #45
Comments
I think the concept is ok but I'm not sure about the implementation. Something like: [[variables]]
name = "infra_repo"
default = "infra/default"
prompt = "Which infrastructure repository should this be linked to?"
# The line below will load all of vars listed and errors if not present
environment_variables = ["ACCESS_TOKEN"]
# and now how to load remote choices.... maybe a nested dict?
[remote_choices]
url = "blabla"
headers = []
names = "$...."
values = "$..." Would that feature be something many people need though? Any other examples to make sure we don't do something too narrow (eg limiting to JSON path). |
oops... I somehow missed this notification, sorry 😕 regarding the implementation syntax... sure, it was just a suggestion how much people would need this? about supporting more than json path... |
GraphQL was what I was thinking of, although you can still use JSON path there anyway. Hopefully no one will want to handle XML or parse HTTP...
What I don't like with this is that one row in the |
Nice project!
It actually seems to be doing some nice things that I wanted cookiecutter to do and I was developing on my own 😅️
What do you think about allowing to populate the choices option dynamically via some API call?
My use case at the moment is that we already have existing resources that we'd like to make references to in templated files, like k8s definitions and vcs projects.
I imagine this being set up somewhat like this:
what kickstart would do in this case would be an API call to the
endpoint
, with the specifiedheaders
and will query the result using JSONPath for both values and labels and zip them together, showing the labels to the users but saving the value when the user acceptsI think that allowing to template headers from env vars or cli flag should be enough to support most auth methods, and for basic auth the credentials can be templated in the endpoint part
so headers should be optional
and labels as well, for when the info displayed to the user can be used also as value
choices can accept a list of this inline tables and make one request per configured endpoint, merging all the results in the end... not sure if this would be needed at some point, otherwise it can be limited to one only, or maybe moved outside of choices
either way... this is just a suggestion implementation, I'm more interested in if you'd be up for adding this feature to kickstart and if you'd be ok with getting and reviewing a contribution on this 🙂️
The text was updated successfully, but these errors were encountered: