byggsteg --origin

the account of a build step: where this console came from, the framework it stands on, and why it was written to be extended rather than configured.

$ byggsteg --origin
[ok] a question asked at GNU: why not the web in Guile?
[ok] 2013-02  Artanis is born at a Guile hack-potluck
[ok] 2015-01  it is offered to the FSF, and becomes GNU
[ok] then     NalaGinrut shows the framework to Josep
[ok] then     a wall becomes a door
[ok] now      a pipeline is a list, and the list is yours
$ 

the short version

byggsteg is the Norwegian word for a build step, and that is the size of the thing: one step, then the next, and then the one nobody has written yet. It is a continuous integration and delivery system written in Lisp, and it is made of five moving parts you can read, run and replace.

a job
a piece of Lisp that returns a plan: the project, the branch to take, where to clone it from and which tasks to run on it
the worker
one loop in one thread, taking whatever the queue holds and doing the steps the job asks for
the log
written as the command prints it, so a run is read while it runs rather than once it is over
the artifact
what a run leaves behind: kept where the deployment can serve it, and swept when it is no longer wanted
the deployment
one SQLite file and one server on a machine of your own, under a licence that lets you take it apart

how byggsteg came to be

There is no first version of this page. Every delivery system is built twice: once by the people who had to deliver before it existed, and once more by whoever inherits the story. This is the second telling of byggsteg's, and it is shorter than the first.

Before byggsteg, a release was a ritual performed by hand. A person signed in to a machine, pulled a branch, built it, restarted a service, and watched. It worked. It always works, for one person, on one machine, at the hour that person happens to be awake. What it could not do was remember what it had done, and what it could not say was why it had failed.

Then two people met, and a door appeared where a wall had stood. Mu Lei, known as NalaGinrut, showed Josep Bigorra, known as jjba23, GNU Artanis, and with the framework came a whole new world of possibilities: pages that are lists, routes that are procedure calls, and a place to put everything a deployment believes about itself. This console is what grew in that world.

The framework itself came out of a question. At GNU, the project was choosing a language for its own website, and many of the answers were Python. That struck NalaGinrut as strange, because the official extension language of GNU is Guile; so he asked instead why nobody had begun a project to write the web in it. RMS agreed it was a good idea. For a while it was only an idea, without a plan. Then the Guile community held a hack-potluck to celebrate Guile 2 turning two — a contest to write something cool in a few weeks — and the framework was born there, in February 2013. It was entered in the Lisp in Summer Projects contest and certified an awesome project; the first stable release arrived on the first of January, 2015; and on the nineteenth of that month it was offered to the FSF, where RMS inducted it as an official GNU project. That is the ground this console stands on.

And so byggsteg was written in that world and named in another. It is a build step, and only a build step: not a platform, not a shelf, not a product with a feature list. The smallest thing that can be asked of a delivery is the thing it was built to answer.

the world that Artanis opened

It is worth saying plainly what was handed over, because it was not a library so much as a country with its borders left open.

a router
a page is announced as a method and a path, and the answer is a procedure of your own
a page
SXML: the page you are reading is a list, built by Scheme, in the same language as the job it describes
a language for the reader
translation is part of the framework, which is why this deployment answers in English, Dutch, Spanish and Japanese
a place for everything
mime types, cookies, static files and a page of its own for each status code: a frame a deployment hangs its own chrome on
a server
the whole console is one process started from one configuration file, with no container between you and it

Of all of it, one sentence did the most work: a page in Artanis is a list, and a list is a program. A system whose interface is a list is a system whose interface can be computed, and a system whose interface can be computed is one nobody has to wait for permission to change.

an infinitely extensible system

Most continuous integration systems are shelves. You take a step down from the shelf, put it in the order the shelf expects, and configure it. A shelf is useful, and a shelf is also a ceiling: what it cannot hold, you cannot do.

byggsteg was built the other way round — it is a library with a page on top — and the library has three doors in it, one for each thing a delivery is made of.

a job is data
a thunk returning an alist, so a pipeline is a value your own program can compute, save as a profile, or send from a phone
a task is a name
the worker looks the name up and runs the clause that answers to it; teaching byggsteg a new verb is adding a clause, not inventing a plugin protocol
a step is a procedure
it is handed the clone directory, announces what it is doing in the log as it does it, and answers with a result — and the trivial task is the door left open for the day a deployment wants something nobody has written yet
;; a job is data, and data can be computed
`((project . "wikimusic")
  (branch-name . "trunk")
  (task . ("maak-test" "maak-deploy")))

;; a verb byggsteg never had: one more clause, and it has it
((equal? task "ring-the-bell")
 (ring-the-bell-step ...))

Nothing in it is finished in the sense of closed. The set of things byggsteg can do is not a list of features somebody chose in advance; it is the set of things the person running it can write down. That is what an infinitely extensible CI/CD system means — not a system with infinite features, but a system whose next feature is a definition.

who made what

Every file of byggsteg carries two copyright lines, and they are the story told plainly: the orchestrator and the framework it is served from, the maintainer who wrote one and the engineer who wrote the other.

byggsteg
Josep Bigorra (@jjba23): the orchestrator, its pages, and hygguile, the interface library they are built from
GNU Artanis
Mu Lei (@NalaGinrut): the framework every page of this deployment is served from, and the second name on each file of this repository
GNU Guile
the language both of them are written in, and the reason a job can be data
Olive CSS
the utility stylesheet the terminal is dressed in, also by @jjba23, under the LGPL
GNU Guix
the manifest that pins the toolchain, so that a build here is a build wherever the pipeline runs
SQLite, Maak, Emacs
the file that remembers, the task runner, and the editor the whole of it was written in

byggsteg is free software under the GNU Affero General Public License, either version 3 or later. Take it, run it on your own machine, read it, break it, and add the step it is missing: that is the door this page is about.