Create webhook to deploy new content
Closed, ResolvedPublic3 Estimated Story Points
Actions

Assigned To

Authored By

	gabriel-wmde
	Feb 8 2017, 3:28 PM

Description

Create webhook in github (https://github.com/wmde/fundraising-frontend-content) that invokes polling in Jenkins (T167096) and hence runs the deployment job to the respective instance(s) when a branch is changed.

AC:

Jenkins has necessary permission (keys) to deploy to fundraising_frontend_test, fundraising_frontend_production
~~webhook endpoint uses key/token~~ AC removed as event merely causes polling which can do little harm even when from fake actor
content gets deployed to fundraising_frontend_test (test branch), fundraising_frontend_production (production branch) respectively
email notification is sent - Receiver list will be looked at during "Editing content" meeting on July 04

Status	Assigned	Task
Resolved	kai.nissen	T157560 Use GitHub Repository for Fundraising Frontend contents
Resolved	gabriel-wmde	T157578 Create branch structure in Content Repo
Resolved	• Pablo-WMDE	T157575 Create deployment of the content repository
Resolved	• Pablo-WMDE	T157577 Create webhook to deploy new content
Resolved	gabriel-wmde	T164943 Outline needed changes to github-webhook
Declined	None	T164945 Extend to wmde/github-webhook to deploy fundraising-frontend-content
Declined	None	T164946 Create deployment playbook for wmde/github-webhook

gabriel-wmde changed the point value for this task from 5 to 8.

• Pablo-WMDE updated the task description. (Show Details)

gabriel-wmde changed the point value for this task from 8 to 3.

Github does not like our SSL setup -> T168710

Github webhook now uses SSL Verification against our Endpoint

there is the AC "webhook endpoint uses key/token", but given how the plugin works I think this can be skipped. The ping will only cause a polling (git ls-remote) - if no change is detected this is it. Do you share the opinion that this is not a sufficient attack vector to warrant creation of another secret that has to be managed?
looks like we can start to get serious about this - what would be the correct receiver list for our deployment emails (incl non-tech people)?

For the time being, I'd be ok with not using a token. Would it be possible to ignore requests from non-github-IPs?
So far, we don't have a mailing list for that. Let's find that who wants to be on it at the introduction for the FR team.

In my eyes, using IPs for auth purposes in this day and age is a Bad Idea™. If you do think there is an attack vector we should address, then let's do it by actual security, using a secret - I just don't think it's necessary
ok. Is this story done despite the incomplete receiver list?

• Pablo-WMDE updated the task description. (Show Details)