On Tue, 2017-10-17 at 12:28 +0100, Ian Boston wrote: > Hi, > > On 17 October 2017 at 12:12, Robert Munteanu <romb...@apache.org> > wrote: > > > On Tue, 2017-10-17 at 12:08 +0100, Ian Boston wrote: > > > Hi, > > > Could travis be used ? > > > > > > https://github.com/apache/sling/blob/trunk/.travis.yml > > > > > > I dont think that need personal access tokens or a special > > > technical > > > uses > > > as it uses OAuth. > > > > > > From memory the main problem with Travis + Sling is a) the size > > > of > > > the log > > > file (fixed for Sling see yml file) and b) the time taken to > > > build. > > > Other > > > than that it works well for small repos that build fast. > > > > Travis requires administrative access to Github, which we don't > > have. > > > > https://travis-ci.org/apache/sling/builds/288988140?utm_source=github > _status&utm_medium=notification > > It seems to be active and working on apache/sling trunk > I don't remember having administrative access to GitHub when making > that > work, but I guess perhaps, Infra had already enabled it.
Apparently it was me asking for it :-) I have a short memory [1] > Enabling once per repo might be more attractive to Infra than having > to > manage 380+ special users, or perhaps thats the same thing. We should be able to work with one 'sling-bot' special user for our Jenkins needs. Or just stick with a committer as a special user. > > > We would need to ask infra to do this, and since they do it > > manually I > > don't think it will be too high on their priority list. > > > > Are we missing features from Travis or is it just the ease of > > configuration? > > > > Ease of configuration (once you get past its output limits) > Good integration with GitHub, especially pull requests. > Doesn't consume Apache resources. (I assume) > > I've used both on other projects and generally found Travis less > hassle > than Jenkins, but thats only my experience. > This has been especially true where I wanted to do a little more PR > validation than a simple build. I think Jenkins pipeline builds are a lot more flexible that 'classic' freestyle of maven builds. I am not a big fan, but they do allow more exotic scenarios. Pull request integration is there with Jenkins as well. As for Apache resources, the ASF currently pays for Travis credits IIUC, see [2],[3],[4] so either way we're consuming something. Anyway, bottom line is that our goal should be 'CI feedback on pull requests', not 'Use Jenkins to validate pull requests'. I did this to make sure we are not making an unwise move in migrating to Github with 280 repos and then finding out we can't easily add validation to pull requests. I am open to either tool and we should definitely evaluate after the git migration has settled down. We should definitely start with "what do we want to validate on a CI" and find out the best tool. One example that would be more interesting to set up is building and testing a bundle and the deploying it in the current Sling launchpad and running the integration tests. Thanks, Robert [1]: https://issues.apache.org/jira/browse/INFRA-6643?jql=project%20%3D %20INFRA%20AND%20text%20~%20travis%20%20AND%20text%20~%20sling [2]: https://issues.apache.org/jira/browse/INFRA-11121 [3]: https://issues.apache.org/jira/browse/INFRA-13634 [4]: https://blogs.apache.org/infra/entry/apache_gains_additional_travi s_ci
