Merge branch 'template' into live

* template:
  fix: specify image name in policy.json (blue-build#176)
  chore: rm deprecated fonts bling from recipe
  fix: ublue-update failure when signing image
  docs: yaml not yml, directions qualifier
  docs: correct title casing in style guide
  docs: grammar recommendations
  docs: chore: remove ":" from Example configuration this change should be propagated to bling
  docs: how to refer to modules in module READMEs
  docs: module working directory, style guides
  chore(ci): Maximize build space (blue-build#165)

.github/workflows/build.yml

@@ -43,6 +43,13 @@ jobs:
 # !!!
 
     steps:
+      - name: Maximize build space
+        uses: AdityaGarg8/remove-unwanted-software@v1
+        with:
+          remove-dotnet: 'true'
+          remove-android: 'true'
+          remove-haskell: 'true'
+
       # Checkout push-to-registry action GitHub repository
       - name: Checkout Push to Registry action
         uses: actions/checkout@v4

build.sh

@@ -23,10 +23,11 @@ run_module() {
     MODULE="$1"
     TYPE=$(echo "$MODULE" | yq '.type')
     if [[ "$TYPE" != "null" ]]; then
+        cd "$CONFIG_DIRECTORY"
         # If type is found, that means that the module config
         # has been declared inline, and thus is safe to pass to the module
         echo "=== Launching module of type: $TYPE ==="
-            bash "$MODULE_DIRECTORY/$TYPE/$TYPE.sh" "$MODULE"
+        bash "$MODULE_DIRECTORY/$TYPE/$TYPE.sh" "$MODULE"
     else
         # If the type is not found, that means that the module config
         # is in a separate file, and has to be read from it

config/recipe.yml

@@ -54,7 +54,6 @@ modules:
 
   - type: bling # configure what to pull in from ublue-os/bling
     install:
-      - fonts # selection of common good free fonts
       - justfiles # add "!include /usr/share/ublue-os/just/bling.just"
                   # in your custom.just (added by default) or local justfile
       # - nix-installer # shell shortcuts for determinate system's nix installers

config/scripts/signing.sh

@@ -11,7 +11,7 @@ cp /usr/share/ublue-os/cosign.pub /usr/etc/pki/containers/"$IMAGE_NAME".pub
 FILE=/usr/etc/containers/policy.json
 
 yq -i -o=j '.transports.docker |=
-    {"'"$IMAGE_REGISTRY"'": [
+    {"'"$IMAGE_REGISTRY"'/'"$IMAGE_NAME"'": [
             {
                 "type": "sigstoreSigned",
                 "keyPath": "/usr/etc/pki/containers/'"$IMAGE_NAME"'.pub",
@@ -24,7 +24,7 @@ yq -i -o=j '.transports.docker |=
 + .' "$FILE"
 
 IMAGE_REF="ostree-image-signed:docker://$IMAGE_REGISTRY/$IMAGE_NAME"
-printf '{\n"image-ref": "'"$IMAGE_REF"'",\n"image-default-tag": "latest"\n}' > /usr/share/ublue-os/image-info.json
+printf '{\n"image-ref": "'"$IMAGE_REF"'",\n"image-tag": "latest"\n}' > /usr/share/ublue-os/image-info.json
 
 cp /usr/etc/containers/registries.d/ublue-os.yaml /usr/etc/containers/registries.d/"$IMAGE_NAME".yaml
 sed -i "s ghcr.io/ublue-os $IMAGE_REGISTRY g" /usr/etc/containers/registries.d/"$IMAGE_NAME".yaml

modules/README.md

@@ -8,6 +8,8 @@ Modules get only the configuration options given to them in the recipe.yml, not
 
 Additionally, each module has access to four environment variables, `CONFIG_DIRECTORY` pointing to the Startingpoint directory in `/usr/share/ublue-os/`, `IMAGE_NAME` being the name of the image as declared in the recipe, `BASE_IMAGE` being the URL of the container image used as the base (FROM) in the image, and `OS_VERSION` being the `VERSION_ID` from `/usr/lib/os-release`.
 
+When running modules, the working directory is the `CONFIG_DIRECTORY`.
+
 A helper bash function called `get_yaml_array` is exported from the main build script.
 ```bash
 # "$1" is the first cli argument, being the module configuration.
@@ -22,4 +24,23 @@ All bash-based modules should start with the following lines to ensure the image
 ```bash
 #!/usr/bin/env bash
 set -oue pipefail
-```
+```
+
+## Style directions for official modules
+
+These are general directions for writing official modules and their documentation to follow to keep a consistent style. Not all of these are to be mindlessly followed, especially the ones about grammar and writing style. It's good to keep these in mind if you intend to contribute back upstream, though, so that your module doesn't feel out of place.
+
+### Bash
+
+- Start with `#!/usr/bin/env bash` and `set -oue pipefail`
+- Don't print "===", this is only for encapsulating the output of _different_ modules in `build.sh`
+- Print something on each step and on errors for easier debugging
+- Use CAPITALIZED names for variables that are read from the configuration
+
+### README
+
+- Title should be "`type` Module for Startingpoint", where the name/type of the module is a noun that shows the module's purpose
+- There should be a subtitle "Example configuration", under which there should be a loosely documented yaml block showcasing each of the module's configuration options
+    - For a YAML block, specify the language as "yaml", not "yml" (MkDocs only supports "yaml")
+- At the start of each paragraph, refer to the module using its name or with "the module", not "it" or "the script"
+- Use passive grammar when talking about the user, ie. "should be used", "can be configured", preferring references to what the module does, ie. "This module downloads the answer to the question of life, the universe and everything..."