While hosted officially on Gerrit, Citoid should be added to this list as well. Its proper functioning depends on Zotero being available, so the current CI tests for Citoid include only syntax checking via jshint. In this case, however, it is unlikely that Travis would help. Ideally, isolated CI instances would allow us to have a Zotero container that could be spun alongside Citoid during tests.

* iOS Mobile app I saw npm-travis when you announced it a while back and was intrigued. The master branch on the wikipedia-ios repo is already building successfully on Travis, so feel free to try triggering builds if that helps with the experiment—but please don't push to master :-). I bet the Android team would also be interested in trying this out to alleviate some of the burden they've shouldered getting our own CI to run Android builds & tests. Ideally, Gabriel beat me to it, but here's a link to docs about using Docker w/in Travis <http://docs.travis-ci.com/user/docker/>. Also, is Zotero stateless? I'd caution against having persistent staging/test service instances to avoid problems caused by: - Accumulated state - Multiple tests being run in parallel Regarding npm-travis specifically, who would own it? It doesn't seem too complex (push to a GitHub repo, get the job id, poll its state), but would C. Scott continue working on it or would RelEng claim it as part of the infrastructure they maintain? Lastly, it appears that Travis's build-triggering API is still in beta <http://docs.travis-ci.com/user/triggering-builds/>, and there's no mention of polling builds in this way. If someone were to try using this with one or more projects (e.g. Android) and decide to move forward, would we reach out to Travis to ask when the current API will be marked as stable or if they would be willing to work with us to develop an API more suited to our needs? I'm all about doing what it takes to get the job done*, but just wanted to be sure that were aware that this might not be the most stable way to use Travis. I also did a quick search to see if there's precedent for this, and found: - travis-build-watcher <https://www.npmjs.com/package/travis-build-watcher>: this is the closest I could find to something that pushes to GitHub to trigger builds & monitor them - node-travis-ci <https://github.com/pwmckenna/node-travis-ci>: not equivalent to npm-travis, but might simplify it if didn't want to re-implement a JS client for Travis * iOS team is using a collection of tools called fastlane <https://github.com/KrauseFx/fastlane> which build, test, and release our app—including using the undocumented (AFAIK) API for iTunes Connect (Apple's service for uploading & managing apps in the App Store). That said, it's widely used, has 90 contributors, and is being actively maintained by the owner. On Fri, Oct 2, 2015 at 9:15 AM, Marko Obrovac &lt;mobrovac(a)wikimedia.org&gt; wrote: > On 1 October 2015 at 22:43, C. Scott Ananian &lt;cananian(a)wikimedia.org&gt; > wrote: > > > We currently have several projects which can not be tested with our > current > > Jenkins test infrastructure, and as a consequence are hosting their > primary > > code repositories on github: > > * RESTBase <https://github.com/wikimedia/restbase> -- missing Cassandra > > support > > * iOS Mobile app > > < > > > https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/083005.html > > > > > -- > > missing OS X platform > > > > While hosted officially on Gerrit, Citoid should be added to this list as > well. Its proper functioning depends on Zotero being available, so the > current CI tests for Citoid include only syntax checking via jshint. In > this case, however, it is unlikely that Travis would help. Ideally, > Cheers, > Marko > > > > > > Other projects can only run a small portion of their test suite via > > Jenkins: > > * mw-ocg-latexer > > < > > > https://github.com/wikimedia/mediawiki-extensions-Collection-OfflineContent… > > > > > -- requires LaTeX from PPA, image utilities (`jpegtran`). > > > > An alternative to allow these apps to be hosted on Wikimedia > infrastructure > > (gerrit, eventually phabricator) is to allow travis integration with > > jenkins as an optional service. > > > > npm-travis <https://github.com/cscott/npm-travis> ( > > https://github.com/cscott/npm-travis) is a tool which will trigger > Travis > > builds from NPM by pushing to a throwaway branch, which is then cleaned > up > > after the tests complete. It integrates well with the Gerrit access > > control mechanism: the "Travis Bot" user can be granted push access > only, > > and only to branches prefixed with `npm-travis/`, so it cannot be used > to > > push changes to the master or deployment branches. > > > > This isn't a replacement for our jenkins test infrastructure, but it > allows > > us to accommodate oddball repositories without taxing our infrastructure > > team or resorting to offsite repository hosting. > > > > There are WIP patches for integrating `npm-travis` with our jenkins > > infrastructure (https://gerrit.wikimedia.org/r/173045, > > https://gerrit.wikimedia.org/r/173046) but they seem to be blocked on > > policy disagreements. This RFC aims to resolve the policy issues. > > > > This RFC in Phabricator: https://phabricator.wikimedia.org/T114421 > > --scott > > -- > > (http://cscott.net) > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > -- > Marko Obrovac, PhD > Senior Services Engineer > Wikimedia Foundation > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle

If we wanted to keep build artifacts around "forever", we could easily do so;

On Fri, Oct 2, 2015 at 11:50 AM, Brian Gerstle &lt;bgerstle(a)wikimedia.org&gt; wrote: <http://docs.travis-ci.com/user/triggering-builds/>, and there's no mention I don't use this API, and it's not really suitable in any case. I just use the standard stable API for watching builds on a branch. Trigger is automatic with the push, which is a boring old git push, via the git CLI. If someone were to try using this with one reach our Not sure exactly what that would be. The only oddity in the current setup is that I clean up the branch right after the build is complete -- but that's not an inherent property of the process. If we wanted to keep build artifacts around "forever", we could easily do so; I just wanted to ensure things were uncluttered in the github "branches" pulldown. I'm all about doing what it takes to get the job done*, but just There's nothing unusual about triggering travis builds by pushing to a branch. The only thing that's interesting at all is that our branch names have slashes in them, and that issue was resolved a year ago: https://github.com/travis-ci/travis-api/pull/146 That property of our branch names was also optional; we used dashes instead of slashes as a workaround. But it does let us integrate better with gerrit access control mechanisms, which are built around slash-delimited branch names. --scott -- (http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Travis is not integrated with gitlab, so it's not really relevant here. *If* travis adds gitlab integration *and* we switch our current github mirror to gitlab *then* it could be something to look at. Neither of those preconditions are currently met. We're not using any "new" github features, just the standard github mirror that gerrit already maintains (and presumably any future change review system would as well). --scott On Fri, Oct 2, 2015 at 7:00 PM, Brian Gerstle &lt;bgerstle(a)wikimedia.org <javascript:;>> wrote: <javascript:;>> <javascript:;>> beta CLI. to branch -- (http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org <javascript:;> https://lists.wikimedia.org/mailman/listinfo/wikitech-l