This page contains news items from the ick project.

Ick ALPHA-6 released: usable by others

After some updates to the ick website, but no significant changes to the software, ick has now reached ALPHA-6. It has, demonstrably, been deployed and used by other people than its primary developer.

Ick can, right now:

  • Build system trees for containers.
  • Use system trees to run builds in containers.
  • Build Debian packages.
  • Publish Debian packages via its own APT repository.
  • Deploy to a production server.

There’s still many missing features. Ick is by no means ready to replace your existing CI/CD system, but if you’d like to have a look at ick, and help us make it the CI/CD system of your dreams, now is a good time to give it a whirl.

Ick ALPHA-5 released: notifications

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

The fifth ALPHA version (0.52) of ick has now been released. The hightlight feature is notifications: ick can now send an email with the build log after a build finishes. Other changes can be seen in the NEWS file snippet below.

The ALPHA-6 cycle of ick development will concentrate on improving documentation (both sysadmin and user documentation), as well as making the deployment process smoother. By the end of ALPHA-6 we will invite people to try ick for real.

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

NEWS for ick2, a CI server

Version 0.52, released 2018-06-11

  • Add a notification service, which sends the build log when a build ends. Also, make the controller invoke the notification at the end of each build.

Version 0.50, released 2018-04-28

  • Add populate_workspace action.

Version 0.49, released 2018-04-27

  • The rsync action now deletes files from the target if they’re not in the source.

Version 0.48, released 2018-04-27

  • New action to do git clone or git remote update.

  • New action to do rsync -av from a directory in the workspace to a remote server.

  • New action to do dput *.changes in the root of the workspace, to upload Debian packages to the APT repository that is part of an ick cluster.

Version 0.47, released 2018-04-25

  • Worker manager now sets LC_ALL and DEBIAN_FRONTEND variables inside the container.

  • Each action in a pipeline MUST now have a where field. Previously you could leave it out and it would act as if where: host was specified.

  • All commands run by worker manager now get their stdin redirected from /dev/null.

  • icktool delete command can now delete projects and pipelines.

Version 0.46, released 2018-04-22

  • The populate_systree action now takes the name from the systree_name parameter, if no systree_name field is given, or its value is auto.

  • New command: icktool show-latest-log PROJECT.

  • icktool make-it-so now accepts filename from which to read project and pipeline descriptions.

  • icktool --no-verify-tls now actually works.

Version 0.45, released 2018-04-21

  • Force new release, since the previous one failed to build right. Again. This is why I am writing CI software.

Version 0.44, released 2018-04-21

  • Force new release, since the previous one failed to build right.

Version 0.43, released 2018-04-21

  • icktool status is now faster. Previously it was linear to the number of projects, now it is as fast for one as for a hundred. Also, the list of projects is now sorted by project name.

  • icktool show-log has been added.

  • icktool show can show any JSON resource (not logs) and needs to be given the URL path component.

  • icktool make-it-so now updates existing projects and pipelines.

  • icktool trigger now takes any number of projects to trigger on the command line.

Version 0.42, released 2018-04-20

  • icktool status, icktool trigger commands added.

  • icktool build-graph PROJECT [BUILD-ID] command added. It writes out a .dot file for showing the build graph for a build. Feed that to dot(1) for processing. Works for a running build as well as older builds.

Version 0.41, released 2018-04-20

  • icktool is now the rewritten version.

  • The controller now allows triggering an entire project, instead of a pipeline in a project. Additionally, when the project build starts, all actions from all pipelines are queued for the build.

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.