summaryrefslogtreecommitdiff
path: root/src/content/blog/2020/08/10/guix-srht.adoc
diff options
context:
space:
mode:
authorEuAndreh <eu@euandre.org>2025-03-30 17:34:46 -0300
committerEuAndreh <eu@euandre.org>2025-03-30 17:34:46 -0300
commit7979d77fa8aca002282ad1e4c03e1244aa5d1dd1 (patch)
treee2514b61f76f81379a91092bd76440c37aded1e6 /src/content/blog/2020/08/10/guix-srht.adoc
parentsrc/content/security.txt: Derive it (diff)
downloadeuandre.org-7979d77fa8aca002282ad1e4c03e1244aa5d1dd1.tar.gz
euandre.org-7979d77fa8aca002282ad1e4c03e1244aa5d1dd1.tar.xz
src/content/blog/: Upgrade 4 files to asciidoc
Diffstat (limited to 'src/content/blog/2020/08/10/guix-srht.adoc')
-rw-r--r--src/content/blog/2020/08/10/guix-srht.adoc87
1 files changed, 43 insertions, 44 deletions
diff --git a/src/content/blog/2020/08/10/guix-srht.adoc b/src/content/blog/2020/08/10/guix-srht.adoc
index 4d7e8d5..b450da2 100644
--- a/src/content/blog/2020/08/10/guix-srht.adoc
+++ b/src/content/blog/2020/08/10/guix-srht.adoc
@@ -1,30 +1,24 @@
----
-title: Guix inside sourcehut builds.sr.ht CI
-date: 2020-08-10
-updated_at: 2020-08-19
-layout: post
-lang: en
-ref: guix-inside-sourcehut-builds-sr-ht-ci
----
-After the release of the [NixOS images in builds.sr.ht][0] and much
-usage of it, I also started looking at [Guix][1] and
-wondered if I could get it on the awesome builds.sr.ht service.
-
-[0]: https://man.sr.ht/builds.sr.ht/compatibility.md#nixos
-[1]: https://guix.gnu.org/
-
-The Guix manual section on the [binary installation][2] is very thorough, and
-even a [shell installer script][3] is provided, but it is built towards someone
-installing Guix on their personal computer, and relies heavily on interactive
-input.
-
-[2]: https://guix.gnu.org/manual/en/guix.html#Binary-Installation
-[3]: https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
+= Guix inside sourcehut builds.sr.ht CI
+
+:nixos: https://man.sr.ht/builds.sr.ht/compatibility.md#nixos
+:guix: https://guix.gnu.org/
+:binary-inst: https://guix.gnu.org/manual/en/guix.html#Binary-Installation
+:shell-inst: https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
+
+After the release of the {nixos}[NixOS images in builds.sr.ht] and much usage of
+it, I also started looking at {guix}[Guix] and wondered if I could get it on the
+awesome builds.sr.ht service.
+
+The Guix manual section on the {binary-inst}[binary installation] is very
+thorough, and even a {shell-inst}[shell installer script] is provided, but it is
+built towards someone installing Guix on their personal computer, and relies
+heavily on interactive input.
I developed the following set of scripts that I have been using for some time to
-run Guix tasks inside builds.sr.ht jobs. First, `install-guix.sh`:
+run Guix tasks inside builds.sr.ht jobs. First, `install-guix.sh`:
-```shell
+[source,shell]
+----
#!/usr/bin/env bash
set -x
set -Eeuo pipefail
@@ -62,15 +56,18 @@ ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix .
ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon .
guix archive --authorize < ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub
-```
+----
-Almost all of it is taken directly from the [binary installation][2] section
-from the manual, with the interactive bits stripped out: after downloading and
-extracting the Guix tarball, we create some symlinks, add guixbuild users and
-authorize the `ci.guix.gnu.org.pub` signing key.
+Almost all of it is taken directly from the {binary-inst}[binary installation]
+section from the manual, with the interactive bits stripped out: after
+downloading and extracting the Guix tarball, we create some symlinks, add
+guixbuild users and authorize the `ci.guix.gnu.org.pub` signing key.
-After installing Guix, we perform a `guix pull` to update Guix inside `start-guix.sh`:
-```shell
+After installing Guix, we perform a `guix pull` to update Guix inside
+`start-guix.sh`:
+
+[source,shell]
+----
#!/usr/bin/env bash
set -x
set -Eeuo pipefail
@@ -79,12 +76,13 @@ sudo guix-daemon --build-users-group=guixbuild &
guix pull
guix package -u
guix --version
-```
+----
Then we can put it all together in a sample `.build.yml` configuration file I'm
using myself:
-```yaml
+[source,yaml]
+----
image: debian/stable
packages:
- wget
@@ -103,26 +101,27 @@ tasks:
- docs: |
cd ./songbooks/
guix environment -m build-aux/guix.scm -- make publish-dist
-```
+----
We have to add the `guix-daemon` to `~/.buildenv` so it can be started on every
-following task run. Also, since we used `wget` inside `install-guix.sh`, we had
+following task run. Also, since we used `wget` inside `install-guix.sh`, we had
to add it to the images package list.
After the `install-guix` task, you can use Guix to build and test your project,
or run any `guix environment --ad-hoc my-package -- my script` :)
-## Improvements
+== Improvements
+
+:repository: https://git.sr.ht/~sircmpwn/builds.sr.ht
When I originally created this code I had a reason why to have both a `sudo`
call for `sudo ./scripts/install-guix.sh` and `sudo` usages inside
-`install-guix.sh` itself. I couldn't figure out why (it feels like my past self
-was a bit smarter 😬), but it feels ugly now. If it is truly required I could
-add an explanation for it, or remove this entirely in favor of a more elegant solution.
+`install-guix.sh` itself. I couldn't figure out why (it feels like my past self
+was a bit smarter 😬), but it feels ugly now. If it is truly required I could
+add an explanation for it, or remove this entirely in favor of a more elegant
+solution.
I could also contribute the Guix image upstream to builds.sr.ht, but there
-wasn't any build or smoke tests in the original [repository][4], so I wasn't
-inclined to make something that just "works on my machine" or add a maintainence
-burden to the author. I didn't look at it again recently, though.
-
-[4]: https://git.sr.ht/~sircmpwn/builds.sr.ht
+wasn't any build or smoke tests in the original {repository}[repository], so I
+wasn't inclined to make something that just ``works on my machine'' or add a
+maintainence burden to the author. I didn't look at it again recently, though.