There’s a variety of discussion around the short-comings of notifications in CircleCI 2.0. I’m going to summarize the three main issues my team has run into, resulting in disabling native notifications and implementing our own, limited, stop-gap workaround. This is a serious problem for us moving forward with CircleCI: build notifications are critical for keeping our delivery pipeline running well.
- Not possible to limit notifications to specific branches. The 1.0 “experimental” syntax does not work. This ultimately led us to disable notifications since we got lots of notifications about WIP branches. All we really care about is the master branch and possibly some other ones.
- Workflow notifications are broken / lie about a build being fixed. Let’s say a workflow with two jobs (A and B) fails because job B failed. On the next run, when job A succeeds, we get a notification that the build is fixed, even though the failing job B hasn’t passed.
- Multiple notifications for a single broken workflow. We consider our pipeline broken when any job in it fails. It doesn’t matter if 5 jobs failed or 1, but if it’s 5 jobs that are failing (probably for the same reason), we’ll get 5 notifications. We just want one.
The reason we picked CircleCI is it’s one of the few cloud provided CI systems that has first class support for delivery pipelines. However, a lack of usable notifications means we have lost visibility into the real-time health of our pipelines.
We’ve been talking to sales about our consultancy joining the reseller/partner program. We brought up the issues with notifications in December and were told they were going to be taken care of in early January. That doesn’t seem to be the case. Looking through the threads in the forum here, it’s not clear there is any priority to fixing these.
This is so close to a great product! However, it’s hard to justify using it in a professional setting when you can’t receive proper notifications about the health of your pipeline.