public inbox for
 help / color / mirror / Atom feed
From: Mark Wielaard <>
Cc: "Arsen Arsenović" <>,
	"Gerald Pfeifer" <>,
	"Nick Clifton" <>,
	"Dodji Seketeli" <>,
	"Jose E. Marchesi" <>
Subject: Using builder for (documentation) snapshots
Date: Sun, 9 Apr 2023 13:30:50 +0200	[thread overview]
Message-ID: <> (raw)


Thanks to OSUOSL we now have an extra buildbot worker with extra
storage so we can do container builds and publish (documentation)

It acts like a normal buildbot (x86_64) container worker, except that
whatever is left in the output directory will be available through the
snapshots server.

Some examples of where this is useful:

- elfutils test coverage reports. Currently they are only produced (by
  hand) once an official release is made. Ideally we have coverage
  reports of current git.

- snapshots of binutils or gnupoke which are either currently done by
  hand (and so need a script to be written to automate) or which have
  a non-trivial boostrap script.

- generating the gcc documentation using the lowest and highest
  supported version of texinfo to make sure it works and looks as

- Generating the documentation/website of libabigail which is
  currently done by hand and needs a specific setup to generate from
  the source code with sphynx.

- valgrind the html and pdf manuals are currently only generated by
  hand during a release.

- is automatically generated through a git hook from the
  main branch, but people have wanted to show how things look from a
  specific branch.

There is an example of how to do the elfutils coverage report in
This also contains the setup instructions of the snapshots server plus
scripts used. The output can be seen here:

I'll help setup the other examples.


The server has 600GB free storage, so even if we really create a new
snapshot every 15 minutes we have some way to go. We could install a
script that scrubs snapshots after a year, or that only keeps one
snapshot a day after a month. A snapshot can be recreated from some
git checkout and aren't intended to be official releases so we can
erase them whenever we want. We just need to write a script to do it.

Write back

Although the original idea was that the "latest" snapshot could be
written back to the webserver dir and/or htdocs git
repo I didn't add such functionality. It is probably better to see how
useful these documentation/web snapshots are before replacing existing
update machanisms.



             reply	other threads:[~2023-04-09 11:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-09 11:30 Mark Wielaard [this message]
2023-04-11  8:19 ` Mark Wielaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).