[Feature request] Vanity/Custom Tokens in Webhooks

[ibnesayeed]

Now that we have webhooks system (#2161), we can evolve it to add more features to it. As per #1663 (comment), it will be nice to have an optional vanity/custom token field associated with each webhook. This can either be the primary token or an alias to a randomly generated token. Even having the ability to associate multiple tokens to a single resource as independent records would work too.

For the UI we can add a button next to the "Copy link" button that says, "Customize token" or "Vanity token". Clicking that button should reveal an text input field to enter a string. This input field should be validated to have only safe characters (such as no spaces) and also it should be made sure that the record is not a duplicate of any existing token. Upon saving the record, either the main link is updated or a secondary link is displayed underneath the first one (depending on whether we decide to make the vanity token the primary token or an alias).

[ibnesayeed]

One benefit of custom tokens would be their predictability based on some out of band naming scheme. For example, a teacher has 30 students in a programming class where each students is supposed to work on a web project. Their code is deployed on a Docker-based server using Portainer. To trigger updates manually or in automated fashion, webhooks can be utilized. Now, the teacher can email individual students and tell them their random webhook URL, but this will be a lot of work and will have to be repeated if for whatever reason tokens are lost and were recreated. On the other hand if the teacher can define a token naming scheme that combines the course number and school login id of students, then a single email will allow everyone know how their webhook would look like. There can be other places where certain patterns are followed in repeated tasks to leverage convention over configuration.

[cmizzi]

Also, it should be great if a token can update multiple services based on the same image.

For example : many of my services use the same image. Every time a new service is created, I have to add a new URL webhook to my ci. I would be nice if the webhook can be applied on many services and use a single URL in the deployment process.

[namnhcntt]

Should this feature is implementing? I think this feature is awesome.

[danschmidt5189]

Relatedly, it would be really useful if this could be dynamically configured via labels. My team has a fairly robust infrastructure-as-code/change management process, with a glaring omission being having to login to Portainer to setup Webhooks via the UI. Adding control over webhooks via the API would be nice, but it's an added step compared to what we've already implemented for services like Traefik which are configured via service labels.

Not to be overly prescriptive, but that might look something like this (in our standard Stack configurations):

services:
  my_service:
    deploy:
      labels:
        portainer.webhook.enable: "true"
        portainer.webhook.id: my-vanity-token

The expected behavior would be that, for services having the portainer.webhook.enable=true label, Portainer sets up a Webhook at /api/webhooks/{portainer.webhook.id}. When someone POSTs to that webhook, it triggers a docker service update --force for the given service. If a webhook with that ID already exists, Traefik should log a warning and not create a new one.

It's a significant feature, and I'm not sure how interested the Portainer team is in developing and maintaining it. But I do think it's useful, and it's inline with the pattern established by other important Swarm projects like Traefik (huge) and crazy-max/swarm-cronjob (tiny, but widely used).

FWIW this is another way of addressing #2573. GitOps is an enormous feature request, and I'm skeptical that it can be done well enough in Portainer to obsolete other ways of doing it (including workflows like mine, which are based on GitFlow, Code Review, and CI). Making Portainer more easily configurable, via the API or labels, offers many of those benefits without overly complicating the project.