CI : build notification webhook URL should be under variable about open-api

[ojongerius]

@raisedadead I dont understand. serverless.yml configures deployment, not build notifications.

[raisedadead]

Yes, I was confused as well, but this is the place where the webhook is configured

open-api/serverless.yml

Line 37 in a339616

url: https://webhooks.gitter.im/e/957145b550e13c6d3a80

[ojongerius]

Actually in 2 places: serverless.yml and .travis.yml. You can't configure Travis notifications much and it would surprise me if it would notify for forks. If it does we probably want to look in alternative way of doing notifications. See https://docs.travis-ci.com/user/notifications/#Default-notification-settings

[ojongerius]

Btw, you are right that forks that use sls deploy will not notify our channel, which we probably do not want. Agreed that is enough reason to put it under a variable.

That still leaves Travis notifications. I'm not convinced they work at the moment, I did get a green buid notification when staging recovered in my mailbox but see nothing on the Gitter channel.

Happy to look into both issues I mentioned above tomorrow.

Notes to self: the Travis integrations works, but only show in the 'activity stream in the right'. This is not what is configured in .travis.yml. If I hit the endpoint in the room settings for "custom" I get a {"error":"Not Found"}. Is this "custom" integration broken? Need to do some testing here..

Ooh annoying, I can't get anything to send to the "custom" integration I've configured, but if I create a new one it works. It's a bit disappointing in that it only shows up in right pane and is very easy to miss.

[raisedadead]

Yes, that's how gitter is setup for notification. I think it in future, we can have a combination of the camperbot and camper-gh-bot doing this for us.

[raisedadead]

I did get a green buid notification when staging recovered in my mailbox but see nothing on the Gitter channel.

Yup.. I have no clue on that, but my fork's builds do end up showing on that sidebar. Which we as a org do not want.

[ojongerius]

Sounds like we want to:

• Remove the Gitter Travis integration as it does not allow fine grained control
• Keep the notifications settings in .travis, but remove the current webhook, create a new one and store it as as secure variable so it is not available to forks
• Update serverless.yml to use the secure variable so local deploys from forks do not announce their deployments for use.

How does that approach sound to you @raisedadead ?

[ojongerius]

A day of Yak shaving! Today I learned:

Webhooks, Gitter and Travis 🤨

• You can add custom webhooks, which do not support much but "message=hey mom". If you let Travis send to the custom webhook you see nothing and get no notification nor error message
• You can configure secret variables, and they are accessible by scripts etc but will be casually ignored by Travis if it's about configuring notifications. If you add and encrypted variable it will work just fine.

Related PR: #118 -sparing you the spurious PRs and commits of me adding ngrok webhooks to see if Travis was actually sending anything and if so what, and adding silly things to break builds.

Yarn vs NPM 💩

serverless-pluging-notification has a maintainer that package accepted changes but did not publish a new NPM package. I fairly quickly found out -as expected that you can just add the git url including commit you want and it Just Works.
however if you then think you are clever and use Yarn, things can fall apart if your toolchain relies on NPM -I guess I hit a bug but am currently out of time, energy or interest to chase that up. In this cases Serverless uses NPM internally and expects npm ls to work as expected. Well it won't 🤪
My hack was to fork the NPM package, bump the version and publish my copied package -I've notified the maintainer of the original package that I'd be happy to nuke it after he gets his act together.
Related PRs maasglobal/serverless-plugin-notification#5 #112

/cc @Bouncey for your entertainment 🍿