DRAFT: What should a Continuous Integration (CI) server do?

Published on 25 January 2023.

This is a work in progress that will change. Like to see it finished? Let me know by sending me an email.

I think that I have figured out what a Continuous Integration (CI) server should do. It is very simple. Yet common CI tools like Jenkins make it hard or near impossible.

What is CI?

A lot of my thoughts on CI here is based on AOAD2, and trying to find the roots of the practice. CI is probably a name that has different meanings to different people.

CI is about two things:

What is integrate?

Tooling for CI should do the following

A CI tool should integrate (merge commits to master) in a “safe” way.

Basics

lock {
    git checkout master
    git merge origin/X (fail/warn if someone else merged before you)

    <command to self tests> (<sha1 of integration comitt to test>)
    // commit build

    git push master
}

<post command>
// secondary build (in mulistage integration build)

// improve:
//   move stuff from secondary bulild -> comitt build

This ensures the following:

Additional functions

Benefit even if not “real” CI

Why don’t CI-severs work like this?

What about pull requests?


Site proudly generated by Hakyll.