Move notification settings to the website #1094

Open
henrikhodne opened this Issue May 6, 2013 · 23 comments

Projects

None yet
Owner

I think moving the notification settings (i.e. the notifications portion of the .travis.yml file) into the web interface somehow is the best way to solve several of our notifications issues. It would fix forks needing different notifications, it would make secure configs easier as notifications is one of the big reason to have secure configs.

Some TODOs:

  • Add configuration to the database. The easiest way to do this would probably to just have a configuration text field for the repository and then merge the dumped YAML/JSON/whatnot from that field to the .travis.yml, although we may want to investigate other ways of doing this.
  • Figure out where on the website we want to put the settings and implement some UI for this.

Any thoughts on how to implement this is appreciated, either on the backend or the frontend.

Owner
joshk commented May 6, 2013

Super jumping high-5 👍 !!

On 6/05/2013, at 8:13 AM, Henrik Hodne notifications@github.com wrote:

I think moving the notification settings (i.e. the notifications portion of the .travis.yml file) into the web interface somehow is the best way to solve several of our notifications issues. It would fix forks needing different notifications, it would make secure configs easier as notifications is one of the big reason to have secure configs.

Some TODOs:

Add configuration to the database. The easiest way to do this would probably to just have a configuration text field for the repository and then merge the dumped YAML/JSON/whatnot from that field to the .travis.yml, although we may want to investigate other ways of doing this.
Figure out where on the website we want to put the settings and implement some UI for this.
Any thoughts on how to implement this is appreciated, either on the backend or the frontend.


Reply to this email directly or view it on GitHub.

Owner

This will also allow us to eventually make the notification settings more flexible, and fix a lot of our email notification issues. We could make an email notification part of the user settings with things like "notify me of builds I break" and we could also let users "subscribe" to repositories and receive notifications for them.

@henrikhodne henrikhodne referenced this issue in nodejs/node-v0.x-archive May 24, 2013
Closed

Add .travis.yml file back #5547

DasBlub commented Jun 3, 2013

as already stated in IRC a few weeks ago, we from @cmangos would really like to move our notification settings so that we'd not get the notifications from forks of our repos. thanks a lot for looking into this! 👍

daira commented Sep 2, 2013

This would be nice; it would allow forks to enable Travis without sending unwanted notifications to our IRC channel.

Owner
joshk commented Sep 2, 2013

In the mean time, you can secure encode the irc details so that forks don't post to your IRC channel as well.

On 2/09/2013, at 9:53 PM, Daira Hopwood notifications@github.com wrote:

This would be nice; it would allow forks to enable Travis without sending unwanted notifications to our IRC channel.


Reply to this email directly or view it on GitHub.

mjtamlyn commented Sep 4, 2013

As an FYI, this is currently the primary blocker to Django using Travis.

Owner
joshk commented Sep 6, 2013

Thanks for the heads up, we definitely need to fix this, but until then you can encrypt the settings, or turn the email notifications off?

On 4/09/2013, at 10:50 AM, Marc Tamlyn notifications@github.com wrote:

As an FYI, this is currently the primary blocker to Django using Travis.


Reply to this email directly or view it on GitHub.

@rummik rummik referenced this issue in expressjs/express Sep 17, 2013
Closed

The build has been broken since Jan 23rd 2013 #1754

The issue I believe is that if we turn the email notifications off in the main repo, and someone turns them back on in their fork, everyone gets emails. As far as I can tell, secure encrypting the settings doesn't help here as someone can just change the file in their fork.

plajjan commented Nov 14, 2013

Just wanted to 👍 this as we would really like to avoid receiving notifications from forks.

dpehrson commented Dec 9, 2013

Also wanted to pop in here to +1 this, so far in using travis getting the notifications stuff has been the most confusing/opaque process in a wonderful system. This seems more like a workflow configuration than a code configuration, so I would agree it should be removed from .travis.yml and moved to the web app.

Hi guys, still no eta about this? You surely understaind how the situation is if 10 people fork your repository and keep original travis.yml file :/

Thank you.

nomis52 commented May 3, 2014

Yet another +1 for this.

Mikaela commented May 11, 2014

👍 Has there been any progress with this issue?

I would like to add notifications to my forks that use Travis, but that would prevent me from sending pull requests to upstream.

I cannot configure Notifico either, because that would require modifying .travis.yml too and adding hooks there.

Limnoria which is another alternative which I am currently using doesn't support all GitHub hooks yet.~~

Notifico has supported GitHub status hook for a long time and it means Travis.

Update: strikethrough the old text and mention notifico. 2014-08-06.

+1

sampsyo commented Sep 13, 2014

One more word of encouragement. Getting IRC notifications from anyone who forks can get pretty noisy! (Keep up the good work, Travis folks.)

Hi guys, any update on this? If this needs an owner, and there is anyone that can point a newbie in the right direction, I'm happy to take a look.

Owner

@petemoore We have this on our radar of things to tackle soon, but no news yet.

Many thanks @roidrage for the swift feedback. :)
I've also discovered https://github.com/lonnen/leeroybot which might work for us (and others too that are blocked on this issue) until this issue is resolved.

lsmith77 commented Dec 4, 2014

+1

+1

Owner
rkh commented Jan 28, 2015

Hi guys, just a quick note: We'll have to lock the issue if you'll keep +1-ing.

We have this feature on the roadmap.

On Wed, Jan 28, 2015 at 5:33 PM, Marc Abramowitz notifications@github.com
wrote:

+1


Reply to this email directly or view it on GitHub
#1094 (comment)
.

Another way to do this is to implement a syntax in the .travis.yml that lets you say these settings apply only to the canonical project and not to forks -- e.g.:

notifications:
  irc: "irc.freenode.org#kotti"
  email: false
  repos:
    - kotti/kotti
@roidrage roidrage locked and limited conversation to collaborators Jan 28, 2015
@NathanW2 NathanW2 added a commit to qgis/QGIS that referenced this issue Feb 7, 2015
@NathanW2 NathanW2 Remove travis notifications in IRC
Anyone who forks QGIS and has Travis will also send stuff to IRC which is annoying.
See travis-ci/travis-ci#1094
66091ca
Owner

#5063 (comment)

I wanted to update #1094 to advise that there is a very neat solution, but unfortunately issue 1094 has been locked so that I can't post to it.

However, here is the solution for the many people that are still interested in this topic.

Simply secure the channel name, like so:
mozilla/build-tools@c13a297

Please can issue 1094 be unlocked to have this information added to it directly?

Many thanks,
Pete

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.