Per account hooks

Problem to solve

Currently hooks are per-repo and require owner's a permission to modify them.

Target audience

Further details

But IMHO there is a better paradigm. Per account hooks.

Releases and commits are public info, and there is a subscribtion mechanism. If a user subscribes on a repo, he gets notifications.

But what if I need to subscribe an app? For example I need GL CI to be activated when a a release with prebuilt binaries is published into some repo in order to rebuild a Docker image dependent on that software. GL allows one to trigger builds via HTTP requests. But currently I would have to ask repo maintainer to add a hook. It is a burden on maintainers. The app is gonna be popular and I guess there will be more Docker images dependent on it.

Proposal

So we need an analogue of an account subscribtion to a repo, but for webapps. In account settings a user specifies a repo, conditions in which trigger is activated and an URI (with templates). Then when the repo is updated GL checks the table with triggers and does the actions. For example there should be a way to send a request if a CI pipeline succeed and an artifact is published.

What does success look like, and how can we measure that?

• \sum_{r \in R}{\frac{#per account hooks on repo r}{#subscribtions on repo r}} where R is the set of all repos on the service

Links / references