|
|
# Core Tor Continuous Integration
|
|
|
|
|
|
## Locations of existing public repositories
|
|
|
|
|
|
(These are the sites hosting official Tor repositories or repositories of individual developers.)
|
|
|
|
|
|
* git.torproject.org (canonical repo is here)
|
|
|
* oniongit.eu (experimental/pilot self-hosted GitLab?)
|
|
|
* gitlab.com
|
|
|
* github.com
|
|
|
|
|
|
## Locations of existing CI platforms
|
|
|
|
|
|
* pixelminers buildbot (BSD architectures only?; fed only by canonical repo on git.tpo)
|
|
|
* jenkins.torproject.org (self-hosted; fed only by canonical repo on git.tpo)
|
|
|
* oniongit.eu (self-hosted GitLab CI; resource-limited; only builds team member repos)
|
|
|
* gitlab.com
|
|
|
* travis-ci.org (fed by github.com)
|
|
|
|
|
|
## Tradeoffs
|
|
|
|
|
|
* GitLab is open source
|
|
|
* GitHub is closed source
|
|
|
* GitHub has a much larger user base. Network effects are important. (Also, we can't really expect external contributors to create an account on our self-hosted GitLab!)
|
|
|
* Travis is easiest for any of us to fix when it breaks. Even external contributors can help if they have a fork! Just editing one file (`.travis.yml` is enough for most things). It also can build stuff pre-merge (including pull requests!).
|
|
|
* Very few people have access to fix Jenkins when it breaks. Its summary output is also hard to read/navigate
|
|
|
* Jenkins covers more platforms, while Travis covers fewer. It also can't build stuff pre-merge.
|
|
|
* Appveyor is one way to get Windows coverage and is about as easy as Travis to set up
|
|
|
* The ability to build (and run tests on) branches and pull requests before they get merged does amazing things to improve code quality and save reviewers effort.
|
|
|
|
|
|
## Changes
|
|
|
|
|
|
* New code review will be in the form of pull requests on github.com. This allows us to see whether a contribution even builds before spending effort manually reviewing it.
|
|
|
* Travis will be our primary CI in that we'll expect it to always work on master or release branches. We'll drop everything to fix it if it breaks.
|
|
|
* Appveyor will probably also be in this category when we get it set up.
|
|
|
|
|
|
## Remaining the same for now
|
|
|
|
|
|
* git.torproject.org is still our canonical repository
|
|
|
* issue tracking remains at trac.torproject.org (pull requests need an associated Trac ticket; we can help newcomers with this if need be)
|
|
|
|
|
|
## To Do
|
|
|
|
|
|
* Taylor will email network-team with near-term recommendations [**DONE**]
|
|
|
* how to set up accounts on github and travis
|
|
|
* major changes (near-term)
|
|
|
* Investigate 32-bit stuff on Travis (e.g., 32-bit package whitelists for containerized builds)
|
|
|
* Set up Appveyor
|
|
|
* Write documentation for contributors
|
|
|
|
|
|
## Stuff to defer
|
|
|
|
|
|
* what to do about the confusing existence of two similarly-named org accounts (torproject and thetorproject) on github.com
|
|
|
* what to do about making accidentally hitting the big shiny merge button less of a problem (it might not be that big a problem in practice) |
|
|
\ No newline at end of file |