Move notification settings to the website

[sarahhodne]

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.

[joshk]

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.

[sarahhodne]

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.

[DasBlub]

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]

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

[joshk]

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]

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

[joshk]

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.

[mjtamlyn]

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]

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

[dpehrson]

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.

[cyberium]

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]

Yet another +1 for this.

[Mikaela]

👍 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.

[hamiltont]

+1

[sampsyo]

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

[petemoore]

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.

[roidrage]

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

[petemoore]

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]

+1

[msabramo]

+1

[rkh]

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)
.

[msabramo]

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

[BanzaiMan]

#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