Integration with Travis CI

[simensen]

It could be a nice way to vet packages when you are searching packagist. Anything that has the green is probably good to go. Anything with red likely won't work. And if nothing at all, you might try to find something that at least has green somewhere on it? :)

Assumes a few things (based on quick IRC conversation):

• Will work for GitHub projects only for now? (Travis CS only works with GitHub currently)
• Will obviously only work for people who have setup Travis (and don't have their own CI)

I'm not sure if this would be making too many assumptions about the environment some people might be coming from. But it might be nice to start thinking about ways to help people make informed decisions about packages found on packagist.

As far as implementation, the thing that made me think about this was seeing this project this morning: https://github.com/l3l0/php-travis-client We could also implement this as the simple image thing they have but it might be nice to have a way to ignore it entirely for projects that don't have travis at all. Also, would be nice to find status on a per-version basis (i.e., build status on tags and branches) instead of just a global "last build" status or "last build on master" status.

[michaelcullum]

+1. Sounds like a good idea, only problem is Travis, although is growing fast, it is still in alpha and isn't yet stable so maybe it would be better to add support for it later on when it is stable?

[stof]

@unknownbliss Packagist is also in alpha :)

[michaelcullum]

IRC: (5:21:04 PM) unknownbliss: Stof: Why would packagist's development status make a difference? (5:24:27 PM) Stof: UKB: an alpha software integrating another alpha software is less an issue than a stable one integration some alpha stuff (5:25:15 PM) unknownbliss: Stof: If composer goes to stable before travis then something stable is using alpha stuff... (5:27:07 PM) Stof: UKB: anyway, many libraries are already using Travis as their CI (5:27:22 PM) Stof: (including Composer btw) (5:27:36 PM) Stof: and the real risk is for them, not for the displayed link (5:27:39 PM) unknownbliss: I agree with that, I use it for my projects. I was just rasing the point. (5:27:58 PM) unknownbliss: I guess so (5:34:08 PM) Seldaek: what are you guys talking about? (5:35:29 PM) simensen: Seldaek: my PR on integrating with Travis. (5:35:36 PM) simensen: er, Issue rather. :) (5:35:38 PM) simensen: Not PR. (5:37:31 PM) Seldaek: ah

[Dynom]

+1 I think it can help in showing how reliable certain packages are and maybe even helps to promote more people delivering well-tested libraries ;-)

[miklosm]

Why restrict to Travis? With a custom format that contains only stuff that any CI server can provide, you could allow package owners to provide either a URL from where their build log could be polled or a URL where they could push their document. A document like this for example could be generated using either travis' or jenkins' API.

{
  "project-url":"http://anyproject.tld/any-ci/",
  "status":"success",
  "last-build":{
    "number":1234,
    "time":"2013-03-07T23:06:10+01:00",
    "url":"http://anyproject.tld/any-ci/build/1234/"
  },
  "last-successful-build":{
    "number":1234,
    "time":"2013-03-07T23:06:10+01:00",
    "url":"http://anyproject.tld/any-ci/build/1234/"
  },
  "last-failed-build":{
    "number":1233,
    "time":"2013-03-07T23:06:10+01:00",
    "url":"http://anyproject.tld/any-ci/build/1233/"
  },
  "previous-builds":[
    {
      "number":1234,
      "result":"success",
      "time":"2013-03-07T23:06:10+01:00",
      "url":"http://anyproject.tld/any-ci/build/1234/"
    },
    {
      "number":1233,
      "result":"failure",
      "time":"2013-03-07T23:06:10+01:00",
      "url":"http://anyproject.tld/any-ci/build/1233/"
    }
    ...
  ]
}

No vendor lock-in, and any CI solution can be used. Required parts should be the project-url, status, last-build parts, all the other stuff can be completely optional. It would meet the notification requirements set out in the OP anyway. Opinions?

[Seldaek]

Those are two separate tihngs IMO: with travis the good thing is that we can auto-discover it and add a travis build img tag. That's fairly easy. For other solutions we need to build this API endpoint that can receive pings, and then show icons based on that, and then people need to configure their CI systems.

[rdohms]

If we are aiming for all the github packages then there is an easier way to get the build state of each branch, because all these CI solutions report back to github witht he "commit status", which we can retrieve for each branch: https://developer.github.com/v3/repos/statuses/

That gives us a standard dataset for build status.

[digitalkaoz]

Why not introduce a New section in composer.json with badge links to various CI quality systems? Think of gravis, scrutinizer, coveralls, versioneye etc...

[digitalkaoz]

Argz damn u autocorrect, but i think you get the point ;)

[eddiejaoude]

:+1: great ideas!!

Any progress on this?