I filed an issue for someone to login to Travis and flick the switch that is needed to keep TravisCI working from the new repository.
https://issues.apache.org/jira/browse/INFRA-9354 Cheers, Peter On 29 March 2015 at 12:33, Peter Ansell <[email protected]> wrote: > On 29 March 2015 at 11:57, John D. Ament <[email protected]> wrote: >> Great question/comment! I always look forward to this part with new >> podlings. >> >> On Sat, Mar 28, 2015 at 5:32 PM Peter Ansell <[email protected]> wrote: >> >>> That is fine with me. >>> >>> I am not overly fascinated by internal Apache infrastructure though so >>> I would like to keep the .travis.yml file and the references to >>> coveralls if possible as there is nothing broken with that system >>> right now for CI and code coverage. >>> >> >> It's weird that you feel this way (from my point of view). Part of why >> projects seek out the ASF is to leverage the infrastructure in place that's >> provided. It's generally expected that the in house services will be >> leveraged. >> >> http://www.apache.org/dev/services.html > > That perspective is very reduced these days by the free set of > services that non-Apache projects generally rely on these days. > > Ie, a project can (and virtually all of my other projects that I am > active with do so) run quite comfortably just with free (for open > source code) providers: > > * GitHub or BitBucket for code hosting, wiki > * GitHub for HTTP hosting and possibly issue tracking > * Free Jira issue tracking license and hosting on Atlassian > Cloud/OnDemand for OSS projects > * TravisCI for continuous integration > * Sonatype OSS Nexus repositories for snapshots and releases > * Coveralls for code coverage > * Google Groups for mailing lists > > In reality, the main reasoning for going to Apache is probably solely > the brand these days, which overcomes the administrative overhead in > the case of mature projects, or in our case, fairly short-lived > projects (in terms of active development, we want to maintain a > consistent core after a short term of stabilisation). > >> I would expect that projects that come in through the incubator will >> leverage the ASF Jenkins instances over external builders. It's fine to >> have external builders, but the official CI for the project would be ASF >> Jenkins. For example, Travis can't deploy to the nexus instances for >> snapshots. > > Yes, the requirement to deploy our future artifacts to Maven Central > through the Apache Nexus instances (not Sonatype OSSRH > Snapshots/Release like non-Apache projects do, and we have done so > far), is a reasonable reason for setting up a Jenkins instance. > However, it doesn't invalidate the much simpler to configure and use > Travis service, even if we don't deploy snapshots through it. If > anything, it will highlight when the Jenkins configuration is broken, > as it most often is when a random bug surfaces that hasn't appeared on > development computers. > > All that supporting Travis and Coveralls into the future will require > is for an admin to setup the TravisCI hook on the GitHub repository, > as has been done in the past for other projects: > > https://issues.apache.org/jira/browse/INFRA-7096 > > Ie, the system is already working with > https://github.com/commons-rdf/commons-rdf, we just need the same hook > setup for https://github.com/apache/incubator-commonsrdf > > Cheers, > > Peter
