A Trigger-Node triggers when the event occurs which got defined for it and then starts the workflow with the data it received.
And even if we would do what you propose, it would “trigger” the workflow to start and not the webhook creation. To do something like that regular nodes exist as it is a simple REST call like all the other things which can be done with the most n8n nodes. It maybe seems like it is related to the Trigger-Node but in the end, if you think about it, it is really not.
Yeah the more I think about it the more I think it would be a nightmare manage. The whole point of a system like n8n is so that you can visualize a static flowchart-like system. If the system is allowed to dynamically change itself, you loose that ability to intuitively visualize it.
I’m trying to just a trigger for changes on any of my repos, so I should probably solve that more directly than trying to dynamically great new trigger nodes. For context, I’m using n8n to automate my iOS deployments. I thought it would be more fun than Jenkins.
How many different repros do you have? Because simply having a Trigger-Node for each, as long as you do not have a hundred of them should then probably be fine.
Ah, great idea! Tell me how it goes. If you realize that some kind of node would be helpful to do that, tell me then I can think about if it would be worth adding to n8n if it could be helpful for many people.
So right now there’s a lot, like 20, but it might become 100s or 1000s later…I’m making a “build-your-own-app app” which will use GitHub. Jenkins might be a better way to go about it, but this project is already so experimental so I thought I’d have fun with n8n first.
What you could do in that case is to use the REST API the Editor-UI uses:
With it, you can simply create new workflows and activate them on the fly. In the end, is each workflow a simple JSON file.
So you could have one main workflow which does the actual work and gets its input data from a webhook and then multiple other workflows (webhook-workflows) that simply contain a webhook node and an HTTP Request Node which triggers the main workflow whenever something changes.
The webhook-workflows would be the ones you can then simply create and activate on the fly whenever a new project gets created on Github.
That API is currently undocumented and was actually just meant to use by the Editor-UI. So it may change in the future. As I can see that it could be quite helpful in many cases to do something like, it is also possible that this API gets improved in the future to be easier to use for such cases.
Anyway, if something would change you would find information about it in the BREAKING-CHANGES file which you should check anyway always before you upgrade to a new version.
I have never tried to have 1,000s of workflows. How many are possible depends then mainly on your hardware. It also depends a lot on how fast you will reach that number. If you think that will happen next week I would maybe not do it. If it is something farther down the line like multiple months or a year then it should be fine as multi-tenancy is anyway on the roadmap for larger enterprise deployments.