People

Agenda

  • Discuss and decide goals for this iteration.

Notes

  • This iteration is about making ick do CI builds of itself, including producing and publishing .deb packages of itself. Note, we aim only at CI builds, and not yet release builds. It turns out that release builds are trickier, partly because they'll need to be built from signed git tags, and that old tags should be ignored. The first time a "release build" runs, it should only remember what release tags exist, and not actually do any building.

  • CI builds are more straighforward: they should always happen, when triggered, and the only tricky part is that the version number for the Debian package should be incremented for each build. Otherwise each build produces packages with the same version number, and that doesn't lead to anything good.

Roadmap until ALPHA-6

Current projects

  • N/A.

Tasks for this week

Tasks may be part of a project or be random small ones (max an hour) that just need doing.

what Who estimate(h)
Add BUILD_NUMBER env vars to builds Lars 1
Set up an ick cluster that CI builds ick Lars 4
Total Lars 5

Task descriptions

  • Add BUILD_NUMBER env vars to builds: Change worker-manager to set the BUILD_NUMBER environment variable for all child-processes it starts. It should get the value from the work resource.

    Acceptance criteria: Manual testing shows it works.

  • Set up an ick cluster that CI builds ick: The cluster should have a project to do CI builds of the ick repository (master branch), such that it mangles the version number to include the build number. Thus, each successful build should result in a new .deb package, with a version number that's strictly larger than the previous one. The project should do uploads to the unstable-ci "release" in the APT repository of the cluster.

    Acceptance criteria: Manual testing shows new .debs get uploaded.