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:
- iOS Mobile app
- missing OS X platform, it was suggested that travis as is isn't enough and that SauceLabs might be able to provide that
- signed builds with a private key we don't want to give is not something that travis can support either, see T114569 for that
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 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.
Mailing list discussion at https://lists.wikimedia.org/pipermail/wikitech-l/2015-October/083446.html
These can be done on WM CI as the required features are available:
- RESTBase -- Cassandra is used in production, it can be set up in WM CI
- mw-ocg-latexer -- requires LaTeX from PPA, image utilities (jpegtran). This can be done with the VMs that are spawned per job run by the WM CI.
- citoid - requires zotero; jenkins only does jshint checking.; The mail already says travis doesn't help here and that it would be nice to be able to spawn a VM, which is now possible.