Opened 6 months ago

Closed 3 weeks ago

Last modified 2 weeks ago

#13716 closed task (wontfix)

Move CI to Jenkins

Reported by: bgamari Owned by:
Priority: normal Milestone:
Component: Continuous Integration Version: 8.0.1
Keywords: Cc: davean, mpickering
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: #13897, #14291 Blocking:
Related Tickets: #11958, #13205 Differential Rev(s):
Wiki Page:

Description (last modified by simonpj)

Currently we use Harbormaster to build Differentials and commits. While this works, it leaves much to be desired:

  • job scheduling is (literally) random: this means that some patch authors end up waiting literally ways for their patches to be built
  • there is little support for automatic provisioning of builders: this means we can't scale to meet demand and make poor use of our computational resources
  • periodic builds (e.g. nightlies) are not supported.
  • it lacks a sensible interface for integration with external tools: this means that efforts like CI-before-merge have been pushed off
  • status reporting is poor: even answering the question of what a given builder is currently working on is surprisingly difficult
  • common maintenance tasks are byzantine: Adding a new builder requires adding at least six different objects (a Harbormaster Build Plan, a Drydock Working Copy, a Drydock Blueprint, an Almanac Service, an Almanac Device, and an Almanac Binding) in various Phabricator applications. None of this configuration can be tracked under version control nor can most of it be cloned from an existing builder's configuration.
  • Design assumptions don't match GHC's constraints: Harbormaster was designed under the assumption that builds are cheap and computation plentiful. The maintainers have stated that they have little interest in supporting environments where this doesn't hold.

Jenkins, while far from perfect, seems a bit better suited to our needs, more mature, and far more flexible. This ticket will serve as the checklist for our move to Jenkins.

See Ben's blog post (Aug 17).

In the end we want,

  • Builders (static or dynamically-provisioned, as appropriate) for
    • x86-64, i386 Linux
    • x86-64, i386 Windows
    • x86-64 Darwin
    • x86-64 OpenBSD
    • Cross compile from x86-64 to ARM
    • Native ARM
  • Differential builds with sensible scheduling (e.g. first build on 64-bit Linux where machines are cheap, then build on the others)
  • Per-commit builds on all
  • Nightly builds on all, including
    • Collection of binary distribution for user download
    • Update of master documentation mirror on downloads.haskell.org
    • Slow validation (including tests requiring Hackage packages)
    • nofib run on some platforms?
  • Test-before-merge-to-master

Change History (10)

comment:1 Changed 4 months ago by Ben Gamari <ben@…>

In 54d3a1f/ghc:

testsuite: Produce JUnit output

Test Plan: Validate, try ingesting into Jenkins.

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #13716

Differential Revision: https://phabricator.haskell.org/D3796

comment:2 Changed 4 months ago by bgamari

Blocked By: 13897 added

#13897 needs to be resolved before we can move forward on this. I'm looking at options for accomplishing this. It may ultimately be easier to test using Hadrian from the beginning to avoid having to fix this under the limitations of the existing build system.

Last edited 4 months ago by bgamari (previous) (diff)

comment:3 Changed 4 months ago by bgamari

Description: modified (diff)

comment:4 Changed 4 months ago by bgamari

Description: modified (diff)

comment:5 Changed 3 months ago by simonpj

Description: modified (diff)

comment:6 Changed 3 months ago by refold

Is there any chance Cabal/cabal-install could piggyback on this effort? We've outgrown free services like Travis and AppVeyor and could use support for additional platforms (OpenBSD and maybe ARM) too.

comment:7 Changed 2 months ago by bgamari

comment:8 Changed 2 months ago by bgamari

Blocked By: 14291 added

comment:9 Changed 3 weeks ago by bgamari

Resolution: wontfix
Status: newclosed

Well, it's more-or-less official at this point. GHC will be moving not to Jenkins but rather to CircleCI and Appveyor. See the rather lengthy thread on the ghc-devops list for details.

comment:10 Changed 2 weeks ago by bgamari

Component: NoneContinuous Integration
Note: See TracTickets for help on using tickets.