Also, sorry if this all should've gone in Phab and not email. I can transcribe to Phab if we'd rather continue discussion there.
On Fri, Oct 2, 2015 at 11:50 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
- iOS Mobile app
< https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/083005.html
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,
isolated CI instances would allow us to have a Zotero container that could be spun alongside Citoid during tests.
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 mobrovac@wikimedia.org wrote:
On 1 October 2015 at 22:43, C. Scott Ananian cananian@wikimedia.org 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, isolated CI instances would allow us to have a Zotero container that could be spun alongside Citoid during tests.
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-OfflineContentG...
-- 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@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@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