Lightweight Erlang continuous integration
JavaScript Erlang Other
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.

README.md

kha

Lightweight Erlang continuous integration server.

Goals:

  • Lightweight
  • Easy to setup
  • Easy to use
  • Extensible

Planned features:

  • Support for rebar
  • Git support
    • per branch builds
  • Git config setup
  • Support for unixy build scripts
  • Plugins support
    • Notifications
    • Hooks - pre-build, post-build, etc.
  • One file deployment
  • Web UI for reports

Notifications:

  • Jabber
  • Email
  • other via plugins

Sandboxing

Kha supports sandboxing via "lxc" containers. Tested on Ubuntu 12.10. Requires a kernel at least 3.5.0-21. For "lxc" to work, Kha has to be run under a user with password-less sudo permissions.

It is configured by changing support/kha.config file:

[{kha, [{host, "example.com"},
        {xmpp_backend, ["kha@example.com", "jabber.example.com", "password"]},
        {container, lxc},
        {container_name, "cibase"},
        {container_opts, [{ephemeral, true},
                          {username, "ubuntu"}]}
 ]}].

User specified in username in container_ops should have password-less sudo access for commands like sudo apt-get install -y package to work.

Road map

v0.1 DONE

  • Single project, build once, show build results

v0.2 DONE

  • Multiple projects, multiple builds, proper JS model

v0.3 DONE

  • Build queueing

v0.4 DONE

  • Re-building, build results history

v0.5 DONE

  • Hooks, build timeouts

v0.6 DONE

  • [ci skip] support,
  • project git change polling
  • user authentication

v0.7 DONE

  • Build list paging
  • email notifications
  • Jabber/XMPP notifications

v0.8

  • line-by-line build log updates [DONE]
  • basic .travis.yml support, [DONE]
  • build sandboxing using lxc [DONE]

v0.9

  • support for multiple Erlang versions via kerl [DONE]
  • GitHub webhook support [DONE]
  • simple tracking depending in the project
  • change project ID from integer to {user, project} (see '0.9 new ID')

v1.0

  • implement global build queue page as a main page
  • implement pubsub
  • non-duplicate process for equal (identical) depending using internal pubsub
  • realtime data push
  • stable release

v1.1

  • support GitHub basic OAuth authorization
  • remote builders
  • branch list page
  • UI for user profile
  • add support for per-repo ssh keys

v1.2

  • complex notification options
  • IRC notifications

v1.3

  • SVN/CVS support

v1.4

  • Replace distributed Erlang with some MQ protocol

v2.0

  • use user/project convention
  • Support foreign architectures using Vagrant/KVM

v0.9 new ID

My suggestion:

Project ID:

  • erlang: {user_name, project_name}
  • REST API:
    • get all project: GET /user
    • get project: GET /user/project
    • add new project: POST /user
    • update project: POST /user/project

Build ID:

  • erlang: {project_id, integer}
  • REST API:
    • get all builds: GET /user/project/build
    • get build: GET /user/project/build/id
    • delete build: DELETE /user/project/build/id
    • run build: POST /user/project/build
    • rerun build: POST /user/project/build/id

v1.0 architecture

Rough sketch of v1.0 architecture:

  1. Angular.js on client side
  2. SockJS for communication, hence allowing to connect to any remote server
  3. Server side
    • Control node
    • Builder node

Control node:

  • mnesia for storing projects and builds
  • project as a process

Project:

  • name
  • load config from .travis.yml
  • build in place OR
  • git clone url
  • build instructions (manual or from git/config)

Builder:

  • queue manager
  • builder as a process

Communications:

  • Both project and builder processes will be broadcasting updates with gproc:bcast/3
  • Session process will subscribe to appropriate keys

Notifications

  • Notificators will be independent processes which will be getting broadcasts from builders/processes