Today, when configuring a webhook notification, you are able to filter which branches send notifications, which is very powerful and useful. However, when it comes to filtering which pipelines send notifications, the options are either “all” or selecting each pipeline manually with a checkbox.
While users with a limited number of pipelines may not find this cumbersome, for larger organizations with literally thousands of pipelines, this becomes very unscalable and unmaintainable, especially with no API available to manage the opt-in list.
I humbly propose adding a pipeline filtering option, very similar to the existing branch filtering option. Users could type in a glob or other syntax to match against the pipeline slug. This allows for a one time notification configuration that works based on conventions, instead of a manual process to opt-in a pipeline when it is created.
For example: “*-release-build” would match against pipelines that end with the “release-build” suffix.
We were pretty frustrated with the lack of flexibility here, too. That’s why we built pipeline notifications:
They give you control over notifications at the pipeline level, and give you conditionals and allow you to use code for flexiblity. Is that something which could work for you?
Unfortunately, our organization uses an abstraction layer for our pipeline definitions, so we don’t have access to that without a larger change. Also, does that offer any sort of integrity checking such as X-Buildkite-Token?
Ah, interesting. Yeah in that case the only immediate solution I can think of is using “All pipelines” and filtering at the receiving end. But this isn’t going to scale well.
We’ll have a think about what we can do on our end. I do like the filtering idea, but I’m not sure if I can make that happen straight away.
And no, build notifications via webhooks don’t support integrity checking at the moment, that’s a good observation.
If we were able to have full CRUD capabilities for “notification services”, including the ability to update the list of enabled pipelines, that could solve our particular needs.
It does not solve, however, the incredibly hard to use UI when “only some pipelines” is enabled…the sea of checkboxes and endless scrolling to get to the bottom to view recent webhook events is…not ideal , but bearable for the few times we need it.
It does not solve, however, the incredibly hard to use UI when “only some pipelines” is enabled…the sea of checkboxes and endless scrolling to get to the bottom to view recent webhook events is…not ideal
That’s a fair point, we’ll have a chat with our design folks about that section of the UI and what we should do about it.
, but bearable for the few times we need it.