This page contains news items from the ick project.

Ick ALPHA-4 released: build and publish .deb packages

Ick is a continuous integration (CI) system. It is starting to be ready for you to use for real. See for more information.

The fourth ALPHA version (0.40) of ick has now been released. Ick now defaults to verifying TLS certificates (all praise Let's Encrypt), code has been cleaned up a bit (especially icktool and worker-manger),l and builds get the BUILD_NUMBER environment variable set.

Thanks to the build number, and changes to the ick2-ansible repository of Ansible playbooks, it's possible to set up an ick instance, with an APT package repository, and have projects build Debian packages, and upload those to the APT repository. The ick2-ansible repository has an example, and liw-ci has an example of an ick project description that does that. This is in production-like use: ick CI builds gets updated whenever that ick master branch changes on the git server.

See NEWS, below, for a more detailed summary of the changes.

Development continues, see the roadmap for what's planned.

NEWS for ick2, a CI server

Version 0.40, released 2018-04-16

  • This is the ALPHA-4 version.

Version 0.39.2, released 2018-04-16

  • Fix build problem.

Version 0.39.1, released 2018-04-16

  • Fix build problem.

Version 0.39, released 2018-04-16

  • Fix bug in worker-manager in how BUILD_NUMBER is set in the environment when running command in container.

Version 0.38, released 2018-04-15

  • Fix bug in worker-manager to set BUILD_NUMBER in environment when running command in container.

Version 0.37, released 2018-04-15

  • icktool trigger now works. There was a bug in how the controller response was printed out.

  • Worker-manager now gives all the child processes it runs the build number as the BUILD_NUMBER environment variable. This lets pipeline actions do things like embed it in Debian package versions for CI builds.

Version 0.36, released 2018-04-08

  • icktool is again mostly functional. Deleting resources (projects, pipelines, etc) hasn't been implemented yet. Neither has handling blobs. These will be added later, when some one needs them.

Version 0.35, released 2018-04-07

  • Controller now knows the URL to the identity provider's authentication endpoint. This is reported via /version, which now doesn't require authentication.

  • Worker-manager and icktool now fetch an access token from the IDP, instead of generating token themselves.

  • icktool has been substantcially rewritten, with much loss of functionality. Lost functionality will be added back as the loss is noticed by users.

Version 0.34, released 2018-04-05

  • icktool --verify-tls now works as intended. worker-manager now has a --verify-tls option. For both programs, the default is "verify". Use --no-verify-tls to turn it off.
Ick ALPHA-3 released: concurrent building, for real

Ick is a continuous integration (CI) system. It is starting to be ready for you to use for real. See for more information.

The third ALPHA version (0.32) of ick has now been released. It fixes building with multiple workers, and expecially the artifact store, which didn't work over a real network connection. See NEWS for a summary of the changes. Download it from the website.

Development continues, see the roadmap for what's planned.

Ick ALPHA-2 released: concurrent building

Ick is a continuous integration (CI) system. It is not yet ready for you to use for real. See for more information.

The second ALPHA version (0.28) of ick has now been released. It allows an installation with multiple workers, and building different projects at the same time. Download it from the website.

Development continues, see the roadmap for what's planned.

Ick ALPHA-1 released

TL;DR: Ick is a continuous integration or CI system. See for more information.

More verbose version follows.

First public version released

The world may not need yet another continuous integration system (CI), but I do. I've been unsatisfied with the ones I've tried or looked at. More importantly, I am interested in a few things that are more powerful than what I've ever even heard of. So I've started writing my own.

My new personal hobby project is called ick. It is a CI system, which means it can run automated steps for building and testing software. The home page is at, and the download page has links to the source code and .deb packages and an Ansible playbook for installing it.

I have now made the first publicly advertised release, dubbed ALPHA-1, version number 0.23. It is of alpha quality, and that means it doesn't have all the intended features and if any of the features it does have work, you should consider yourself lucky.

Invitation to contribute

Ick has so far been my personal project. I am hoping to make it more than that, and invite contributions. See the governance page for the constitution, the getting started page for tips on how to start contributing, and the contact page for how to get in touch.


Ick has an architecture consisting of several components that communicate over HTTPS using RESTful APIs and JSON for structured data. See the architecture page for details.


Continuous integration (CI) is a powerful tool for software development. It should not be tedious, fragile, or annoying. It should be quick and simple to set up, and work quietly in the background unless there's a problem in the code being built and tested.

A CI system should be simple, easy, clear, clean, scalable, fast, comprehensible, transparent, reliable, and boost your productivity to get things done. It should not be a lot of effort to set up, require a lot of hardware just for the CI, need frequent attention for it to keep working, and developers should never have to wonder why something isn't working.

A CI system should be flexible to suit your build and test needs. It should support multiple types of workers, as far as CPU architecture and operating system version are concerned.

Also, like all software, CI should be fully and completely free software and your instance should be under your control.

(Ick is little of this yet, but it will try to become all of it. In the best possible taste.)

Dreams of the future

In the long run, I would ick to have features like ones described below. It may take a while to get all of them implemented.

  • A build may be triggered by a variety of events. Time is an obvious event, as is source code repository for the project changing. More powerfully, any build dependency changing, regardless of whether the dependency comes from another project built by ick, or a package from, say, Debian: ick should keep track of all the packages that get installed into the build environment of a project, and if any of their versions change, it should trigger the project build and tests again.

  • Ick should support building in (or against) any reasonable target, including any Linux distribution, any free operating system, and any non-free operating system that isn't brain-dead.

  • Ick should manage the build environment itself, and be able to do builds that are isolated from the build host or the network. This partially works: one can ask ick to build a container and run a build in the container. The container is implemented using systemd-nspawn. This can be improved upon, however. (If you think Docker is the only way to go, please contribute support for that.)

  • Ick should support any workers that it can control over ssh or a serial port or other such neutral communication channel, without having to install an agent of any kind on them. Ick won't assume that it can have, say, a full Java run time, so that the worker can be, say, a micro controller.

  • Ick should be able to effortlessly handle very large numbers of projects. I'm thinking here that it should be able to keep up with building everything in Debian, whenever a new Debian source package is uploaded. (Obviously whether that is feasible depends on whether there are enough resources to actually build things, but ick itself should not be the bottleneck.)

  • Ick should optionally provision workers as needed. If all workers of a certain type are busy, and ick's been configured to allow using more resources, it should do so. This seems like it would be easy to do with virtual machines, containers, cloud providers, etc.

  • Ick should be flexible in how it can notify interested parties, particularly about failures. It should allow an interested party to ask to be notified over IRC, Matrix, Mastodon, Twitter, email, SMS, or even by a phone call and speech syntethiser. "Hello, interested party. It is 04:00 and you wanted to be told when the hello package has been built for RISC-V."

Please give feedback

If you try ick, or even if you've just read this far, please share your thoughts on it. See the contact page for where to send it. Public feedback is preferred over private, but if you prefer private, that's OK too.

Tentatively ALPHA-1 feature complete

As of the 0.22 release, ick2 should be feature complete for the ALPHA-1 release. This means all the features planned for the release should be there, but there may still be bugs or other things that need to be fixed.