Is this a deliberate exclusion because the functionality is not ready, or is it just a pending TODO?
More generally, the extension does appear to have much more functionality available than what is documented (https://auth0.com/docs/extensions/github-deploy). What is the policy on that? Is available functionality supported, or just what is documented officially?
Finally, is this the best solution for tracking auth0 configuration as code or are there better options?
This folder structure works for our github extension. I followed steps from https://auth0.com/docs/extensions/github-deploy though. Do you get error when you do deploy from here or just that this folder does not get deployed?
I don’t have have a good answer to your last question on if config as code is better or not. But it is definately best for us where we are trying to setup diff env as diff tenants but don’t want to copy-paste all configs again. So build in one place > commit to code and let it deploy to other tenants.
Thanks for the information, but from what I can tell reading the docs and reviewing the code, the database-connections folder is for configuring custom database connections. This is not what I need. Instead, I would like to create and configure standard Auth0 user database connections.
And like you, I do prefer to use configuration as code, I only meant to ask if there was some solution for this which was more complete. I have found some interesting Auth0 terraform plugins for example, but those also seem to be works in progress.
After checking with our support team @svelez, I was able to confirm that we only support deploying scripts that have been defined (e.g. custom db connection scripts and rules) as stated here.
However if you’re up to the task you can automate the tenant setup through the code directly, and leverage the Management API to tackle anything. You could store your configuration as json files, and then call the appropriate API endpoints passing the data from the json configs to recreate everything.
I hope this helps answer your question but if you have any more please feel free to ask. Thanks!
Thanks for the response! I did end up writing a custom script that reads json from disk and posts to the management API since that seemed the most expedient solution. It seems a bit disjoint this way, but it will work.
You mention that what is stated on the referenced documentation page for the github extension is what is supported, but I have discovered that in addition to what is documented, configuration of clients/applications and resource-servers/APIs also “works” there may be other bits I haven’t tried or looked for because I didn’t need it. Does this functionality’s unsupported status simply mean “use at your own risk”, or “it may not be there tommorrow…” or something else?
There could be several reasons why various functionality may remain undocumented such as the documentation lagging behind the development of the extension or the functionality not being fully implemented and/or tested yet.
We do not recommend using undocumented features as it is possible that the behavior of these features could change in the future or it may be decided to remove the undocumented feature at some point.
With that being said, you may use undocumented features but we cannot guarantee that we will be able to support any issues that you encounter. If you do encounter issues or bugs with documented or undocumented functionality you may report and issue in the GitHub repo: Issues · auth0-extensions/auth0-github-deploy · GitHub
