Docs: Drop old artifacts and build logs

[jbglaw]

Hi!

Building lots of stuff means to generate lots of logs. During testing, I just deleted the database file and artifacts directory manually every now and then.

However, I think it would be good to move that functionality into laminarc. What do you think?

Thanks,
Jan-Benedict

[ohwgiles]

1. Since Laminar run scripts are just regular shell scripts (or anything executable), they can easily be tested on their own before having laminar execute them.
2. Laminar is totally happy for you to hack its database (here's an example)

So all in all I am not convinced that it moving it into laminarc provides any benefit other than making it "feel" like a more first-class supported operation, at the cost of lots of boilerplate, RPC etc.

You could "add" this to laminarc by creating a job which takes another job name as a parameter and clears it out, something like the following totally untested code:

clear-history.run:

#!/bin/bash -e

if laminarc show-jobs | egrep "^$job\$"; then
  rm -rf "$ARCHIVE/../$job"
  sqlite3 "$LAMINAR_HOME/laminar.sqlite" "DELETE FROM builds WHERE name = '$job'"
fi

laminarc run clear-history job=foo

[jbglaw]

It's not that easy. From a frontend point of view, missing "builds" for example result in the "left" and "right" buttons on the log-showing page not working properly (at least with the frontend code Debian ships---though I guess Debian's small modifications aren't the root cause.)

[ohwgiles]

Ok makes sense, the latest build numbers are cached in laminar itself, it would need to be restarted after the database is cleaned.

Anyway for me this is not a feature that laminar needs, and I'm not interested in implementing it.

That being said, I would consider merging a well-written patch that implements this, especially if other users express an interest in this.

[jakimfett]

For what it's worth @jbglaw you can actually restart laminard via a Laminar job, so you could create a clear-history.after which could be something like:

#! /run/current-system/sw/bin/bash -ex
sudo systemctl restart laminard.service

(note that to make this work, I had to configure passwordless sudo for the specific command, and the run always fails because laminar sends SIGHUB to child processes)

This could also be done with a script that restarts the Laminar service, but would need to disown the script and have it wait until laminard.service was a status of inactive (dead) before executing the sequence for clearing the history.

[ohwgiles]

A potentially simpler change could just be implementing a laminarc command that reinitializes laminard's connection to the database, including any cached variables. This would be useful after any kind of external manipulation of laminar's database, not just the removal of old artifacts and logs.