Check Travis build status via GitHub instead of Travis hooks

[larsbergstrom]

r? @Manishearth

Fixes servo/servo#12739

cc: @metajack @edunham

---

This change is

[metajack]

@bors-servo r+

[bors-servo]

📌 Commit da33177 has been approved by metajack

[Manishearth]

Has the status privilege been added to homu webhooks everywhere?

[larsbergstrom]

What do you mean? The homu webhook in GitHub is one of the application ones
that is not configurable.

Or did you mean somewhere other than GitHub?

On Wed, Aug 10, 2016 at 10:29 AM, Manish Goregaokar <
notifications@github.com> wrote:

Has the status privilege been added to homu webhooks everywhere?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#454 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAdCxyIC1olz1D3w_qDAryv3UcdOmqVKks5qee5ugaJpZM4JhREd
.

[Manishearth]

The http://build.servo.org:54856/github hook is editable.

[larsbergstrom]

Aha, that one! It's not in the instructions (
https://github.com/servo/servo/wiki/Adding-a-repo-to-Homu), but seems to be
on in most. I'll update the instructions and do a sweep of all the travis
repos. sweep sweep sweep.

On Wed, Aug 10, 2016 at 10:43 AM, Manish Goregaokar <
notifications@github.com> wrote:

The http://build.servo.org:54856/github hook is editable.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#454 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAdCx_fZYSVfPKkJro2vYu8nGfzb9G4Tks5qefGYgaJpZM4JhREd
.

[metajack]

I think back when buildbot used to do this directly, we had added it. I don't think it was previously necessary for homu, but it's been a while since I looked.

This is what my repo_add_homu.sh script does with the github api (tokens removed):

{
    "name": "travis",
    "active": true,
    "events": [
        "push",
        "pull_request",
        "issue_comment",
        "public",
        "member"
    ],
    "config": {
        "user": "bors-servo",
        "token": "**REDACTED**",
        "domain": "notify.travis-ci.org"
    }
}

and

{
    "name": "web",
    "active": true,
    "events": [
        "issue_comment",
        "pull_request",
        "push"
    ],
    "config": {
        "url": "http://build.servo.org:54856/github",
        "content_type": "json",
        "insecure_ssl": "0",
        "secret": "**REDACTED**"
    }
}

[larsbergstrom]

Yeah, I'd say about 1/6th of the repos had it set. I added it to the rest, unfortunately by hand before I saw that comment :-)

[aneeshusa]

@metajack That sounds like a useful script to put on the wiki or in this repo.

[bors-servo]

⌛ Testing commit da33177 with merge de4e7a0...

[bors-servo]

☔ The latest upstream changes (presumably #425) made this pull request unmergeable. Please resolve the merge conflicts.

[metajack]

I could have sworn I've given this script to everyone and it was documented somewhere. If that's not the case, where should I post it so people can find it easily in the future?

[Manishearth]

I'd love to have an etc/ and doc/ folder in the saltfs repo containing scripts and docs and useful stuff. Not very fond of using the wiki for docs, since it's not so visible and has a different history.

[aneeshusa]

I don't think I have that script, but I agree with putting it in the repo (as opposed to having to give it to people).

In #355 I am adding a scripts to a new scripts/ dir - do we want to standardize on etc/ instead? I don't have an opinion either way.

I do think some docs would fit better in the repo (e.g. Vagrant usage instructions) with a pointer from the wiki. However, some things like a list of our EC2 machines or a link to seekrits should stay on the wiki IMO. Let's do docs/ instead for consistency with the main servo repo.

[metajack]

I added my scripts to #457.

[Manishearth]

Works.