wiki:org/meetings/2018NetworkTeamHackfestSeattle/CI

CI session

Taylor gives an overview of what we have now is a big win:

  • External contributors gets their code tested by the CI when they do PR's.

We can potentially break things when PR's are NOT run by CI's such a Jenkins. Taylor suggests moving things away from Jenkins.

BuildKite allows us to run external agents on our own machines.

We should avoid maintaining our own machines because of the additional efforts that is needed.

If there is something Travis doesn't do right now, how do we handle this? We currently do it with Jenkins.

A benefit of Jenkins is that "it's not Travis" (since we test different environments)

Gitlab.com have some new terms that are questionable. Isis adds that gitlab.com's CI runners are also slow.

People agree that latency is important.

Having a fast set on every push and a slower set for PR's.

Can we add other "things" to Travis?

  • Are we OK with saying changes must have coverage? No change we merge must decrease Coverage.
  • Make style checks?
  • A commit comes in without a changes file? Nick says a lot of patches is rejected because of this.
  • MacOS CI? 32-bit and 64-bit
  • 32-bit Linux
  • Android
  • iOS
  • ARM
  • Weasel's ARM machines?

We discuss if it can make sense to use a paid Travis CI.

Actions

  • Break out session on handling build matrix explosion.
  • Update Contributor document to explain the transition to travis-ci.com instead of travis-ci.org (#26286)
  • Investigate more platforms.
  • A Trac/Github service bot. Nice to have? Student project? (#26285)
  • Figure out if other people (GuardianProject) could benefit from Tor paying for Travis?
  • Look into gitlab.com
  • Talk to with the application team about where they are with $TOOLING
  • Look into Nick's "cronjobs" that is run every now and then and get it moved into team ownership via something like Travis: doxygen, call-graph, etc.
Last modified 4 months ago Last modified on Jun 3, 2018, 5:30:20 PM