I've been maintaining Guix System image for builds.sr.ht. I'm taking a

break from software development and maintenance for some time. I'd like
to hand over the maintainarship to ~whereiseveryone. It's a community
where we develop guixrus, a guix channel, here on sourcehut. We rely on
guix image for CI. Folks from ~whereiseveryone (also CCed) and I have
discussed this earlier and they are willing to assume the
responsibilities.

As far as I know, we need to update Guix System section of
man.sr.ht/builds.sr.ht, and triggers section of
builds.sr.ht/images/guix/build.yml with correct maintainer, email, and
links. The development will continue from
~whereiseveryone/builds.sr.ht-guix. We'll make necessary changes to the

---
guix package manager checks out the guix repository when it `guix pull`
is ran. By providing cache from host (current image) to guest (newly
created image), I managed to shave off several minutes of build time and
bandwidth. It was done since guix already is too slow to generate image.

This was both too clever, and too stupid of me. guix doesn't seem to be
cleaning up stale files in that git checkout. The cache has been ever
growing; to the point where it has reached about 4GB.

This cache seems to have become a problem when newly created qcow2 image
is expanding to contain latest guix checkout. I fixed this and it should
stop guix from failing.
[message trimmed]

Ignore the build failure. It's there because I removed manifest.scm
file, which won't be needed with newer .build.yml.

cleanup README.md section and .build.yml task
---
 .build.yml   | 3 ---
 README.md    | 7 +------
 manifest.scm | 3 ---
 website.scm  | 2 +-
 4 files changed, 2 insertions(+), 13 deletions(-)
 delete mode 100644 manifest.scm

diff --git a/.build.yml b/.build.yml
index 3123056..0cb7380 100644
--- a/.build.yml
+++ b/.build.yml
@@ -4,9 +4,6 @@ sources:
[message trimmed]

On Fri May 27, 2022 at 2:06 PM IST, Drew DeVault wrote:
> On Fri May 27, 2022 at 10:33 AM CEST, Moritz Poldrack wrote:
> > Since the suggested approach of just setting up your own server to keep
> > track is not quite feasible for most, I'd like to weigh in with my 2ct
> > as well.
>
> A raspberry pi on your desk would be more than sufficient for this
> use-case.

That's the plan. I already have a prometheus server running on pi and
available via wireguard. I'll expose an instance to the public, as I
have dynamic dns set up.

I think I'll have to write metrics to a prom file, and figure out a way

On Fri May 27, 2022 at 12:49 PM IST, Drew DeVault wrote:
> I do not think that this is a good idea. This feature is far too
> complex and far too narrowly-applicable for builds.sr.ht.

Well, that's sad to hear.

> It would be better to publish your coverage as an HTML artifact, or if
> you want to track it to have it push the details to a separate
> prometheus server or something.

Tracking project metrics with prometheus is new for me. I'll explore my
options. Thanks.

On Fri May 27, 2022 at 2:03 PM IST, Moritz Poldrack wrote:
> You can take the blunt method of updating the README in your repo and
> pushing it with CI disabled (which is probably not preferred for obvious
> reasons), or you could use a pastebin service that allows editing your
> pastes and use a service like shields.io to create custom badges[0] for
> it.

Updating the README will add unnecessary commits to the repo. But I've
seen some projects (not on sr.ht) do it before.

> Those are currently the only ways i can think of to get it done that
> don't require you to have an additional server at hand.
>
> [0]: https://shields.io/endpoint/

# Proposal:

Allow users to specify a build attributes file (in build manifest)
containing build job's attributes as key value pairs (e.g. % of code
coverage, % of successful/failed tests, cyclomatic complexity).

It will be similar to how we offer specifying a list of files as build
artifacts.

1. The attributes will be stored permanently along with its job. Which
will then allow users to point to it via
<instance>/~<user>/<path-to-job>/attributes (returning that json data).

2. The data can also be queried by GraphQL query.

alpine-conf dropped setup-timezone's -z flag used to specify the
timezone and is now accepting it as an arg (in commit 3b793bb).
---
 images/alpine/genimg | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/images/alpine/genimg b/images/alpine/genimg
index 5f103f4..dccef42 100755
--- a/images/alpine/genimg
+++ b/images/alpine/genimg
@@ -82,15 +82,16 @@ iface eth0 inet static
 	gateway 10.0.2.2
 EOF
 run_root setup-dns -d example.org 8.8.8.8 8.8.4.4
[message trimmed]

---
 .guix-authorizations | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.guix-authorizations b/.guix-authorizations
index 7e264bc..5f97733 100644
--- a/.guix-authorizations
+++ b/.guix-authorizations
@@ -6,5 +6,5 @@
    (name "raghavgururajan"))
   ("0B83 7250 5DAF 9C01 A32C  3E4C DC2B ECE8 3E41 C67A"
    (name "unmatched-paren"))
-  ("E415 5859 F845 3421 1511  C3E8 F34B 15C2 7B4C 5C16"
+  ("582C 86C7 57C7 28DE 62B3  FCA2 09D3 0C9F 85F6 FA2C"
[message trimmed]