Expand multiple build capabilities

.gitlab-ci.yml

@@ -8,3 +8,8 @@ include:
       - RECIPE:
           - recipe-desktop.yml
           - recipe-framework-13.yml
+        CONTAINERFILE: Containerfile.j
+        USR_DIR: usr-j
+      - RECIPE: recipe-c.yml
+        CONTAINERFILE: Containerfile.c
+        USR_DIR: usr-c

Containerfile.c

@@ -0,0 +1,44 @@
+# This is the Containerfile for your custom image. 
+
+# It takes in the recipe, version, and base image as arguments,
+# all of which are provided by build.yml when doing builds
+# in the cloud. The ARGs have default values, but changing those
+# does nothing if the image is built in the cloud.
+
+ARG FEDORA_MAJOR_VERSION=38
+# Warning: changing this might not do anything for you. Read comment above.
+ARG BASE_IMAGE_URL=ghcr.io/ublue-os/cinnamon-main
+
+FROM ${BASE_IMAGE_URL}:${FEDORA_MAJOR_VERSION}
+
+ARG USR_DIR=usr-c
+
+# The default recipe set to the recipe's default filename
+# so that `podman build` should just work for many people.
+ARG RECIPE=recipe-c.yml
+
+# Copy static configurations and component files.
+# Warning: If you want to place anything in "/etc" of the final image, you MUST
+# place them in "./usr/etc" in your repo, so that they're written to "/usr/etc"
+# on the final system. That is the proper directory for "system" configuration
+# templates on immutable Fedora distros, whereas the normal "/etc" is ONLY meant
+# for manual overrides and editing by the machine's admin AFTER installation!
+# See issue #28 (https://github.com/ublue-os/startingpoint/issues/28).
+COPY usr-common/ /usr
+COPY ${USR_DIR}/ /usr
+
+# Copy the recipe that we're building.
+COPY ${RECIPE} /usr/share/ublue-os/recipe.yml
+
+# "yq" used in build.sh and the "setup-flatpaks" just-action to read recipe.yml.
+# Copied from the official container image since it's not available as an RPM.
+COPY --from=docker.io/mikefarah/yq /usr/bin/yq /usr/bin/yq
+
+# Copy the build script and all custom scripts.
+COPY scripts /tmp/scripts
+
+# Run the build script, then clean up temp files and finalize container build.
+RUN chmod +x /tmp/scripts/build.sh && \
+        /tmp/scripts/build.sh && \
+        rm -rf /tmp/* /var/* && \
+        ostree container commit

Containerfile.j

@@ -11,9 +11,11 @@ ARG BASE_IMAGE_URL=ghcr.io/ublue-os/kinoite-main
 
 FROM ${BASE_IMAGE_URL}:${FEDORA_MAJOR_VERSION}
 
+ARG USR_DIR=usr-j
+
 # The default recipe set to the recipe's default filename
 # so that `podman build` should just work for many people.
-ARG RECIPE=./recipe-framework-13.yml
+ARG RECIPE=recipe-framework-13.yml
 
 # Copy static configurations and component files.
 # Warning: If you want to place anything in "/etc" of the final image, you MUST
@@ -22,10 +24,8 @@ ARG RECIPE=./recipe-framework-13.yml
 # templates on immutable Fedora distros, whereas the normal "/etc" is ONLY meant
 # for manual overrides and editing by the machine's admin AFTER installation!
 # See issue #28 (https://github.com/ublue-os/startingpoint/issues/28).
-COPY usr/bin /usr/bin
+COPY usr-common/ /usr
-COPY usr/lib /usr/lib
+COPY ${USR_DIR}/ /usr
-COPY usr/etc /usr/etc
-COPY usr/share /usr/share
 
 # Copy the recipe that we're building.
 COPY ${RECIPE} /usr/share/ublue-os/recipe.yml

README.md

@@ -6,79 +6,6 @@ This is a constantly updating template repository for creating [a native contain
 
 For more info, check out the [uBlue homepage](https://ublue.it/) and the [main uBlue repo](https://github.com/ublue-os/main/)
 
-## Getting started
-
-See the [Make Your Own -page in the documentation](https://ublue.it/making-your-own/) for quick setup instructions for setting up your own repository based on this template.
-
-Don't worry, it only requires some basic knowledge about using the terminal and git.
-
-> **Note**
-> Everywhere in this repository, make sure to replace `gmpinder/wunker-os` with the details of your own repository. Unless you used [`create-ublue-image`](https://github.com/EinoHR/create-ublue-image), in which case the previous repo identifier should already be your repo's details.
-
-> **Warning**
-> To start, you *must* create a branch called `live` which is exclusively for your customizations. That is the **only** branch the GitHub workflow will deploy to your container registry. Don't make any changes to the original "template" branch. It should remain untouched. By using this branch structure, you ensure a clear separation between your own "published image" branch, your development branches, and the original upstream "template" branch. Periodically sync and fast-forward the upstream "template" branch to the most recent revision. Then, simply rebase your `live` branch onto the updated template to effortlessly incorporate the latest improvements into your own repository, without the need for any messy, manual "merge commits".
-
-## Customization
-
-The easiest way to start customizing is by looking at and modifying `recipe.yml`. It's documented using comments and should be pretty easy to understand.
-
-For the base-image field, you can use any other native container image. You will get all the features of that image, plus the ones added here! Check out the [uBlue images list](https://ublue.it/images/) to decide what to use!
-
-If you want to add custom configuration files, you can just add them in the `usr/etc/` directory, which is the official OSTree "configuration template" directory. If you need to add other directories, you can look at the Containerfile to see how it's done. Writing to `/etc` or `/var` in Fedora's immutable OSTree-based distros *isn't supported* and will not work, as those are user-managed locations!
-
-> **Note**
-> The configuration files you put in `/usr/etc/` will automatically be applied to your local `/etc/` by `systemd` whenever you rebase an OSTree system or update the image. If a config file in `/etc/` has been *modified* (compared to the same deployment's defaults), then OSTree [won't overwrite it](https://github.com/ostreedev/ostree/blob/16cb47489e582da9c139fee20acdac7079867843/docs/atomic-upgrades.md?plain=1#L76), but the new version will be available in `/usr/etc/`. Run `sudo ostree admin config-diff` to see the difference between `/etc/` and `/usr/etc/` (`man ostree-admin-config-diff` for further documentation).
-
-### Custom build scripts
-
-If you want to execute custom shell scripts or commands in the image build, you shouldn't edit the `scripts/build.sh` or the `Containerfile` directly.
-
-Instead, you should create your own custom shell scripts in the `scripts/` directory (look at the `example.sh`). After creating your scripts, enable them in the `scripts:` section of your `recipe.yml`, within the specific "build stage" category where the scripts are intended to be executed. Alternatively, enable the `autorun.sh` helper script in your recipe to automatically execute your custom scripts.
-
-Read [the README in the `scripts/` directory](https://github.com/gmpinder/wunker-os/blob/main/scripts/README.md) for more information.
-
-### Custom package repositories
-
-If you want to add custom package repositories to your image, you can include them in the `recipe.yml` as a list of URLs under the `rpm.repos:` section. They **must** be proper `.repo` files (such as `https://copr.fedorainfracloud.org/coprs/atim/starship/repo/fedora-38/atim-starship-fedora-38.repo`). In the build process, the `.repo` file will be downloaded and placed inside `/etc/yum.repos.d/` where rpm-ostree can access it.
-
-You can use this to add [COPR repositories](https://copr.fedorainfracloud.org/) to your image.
-COPR is like the Arch User Repository for Fedora, where you can find extra packages that wouldn't otherwise be available. The repositories are community-created, so use them at your own risk. [Read more](https://docs.pagure.org/copr.copr/user_documentation.html)
-
-Tip: You can use the magic string `%FEDORA_VERSION%` in your repo URLs, to automatically refer to the correct repository for your current Fedora version.
-
-### Building multiple images
-
-You can build multiple images using multiple `recipe.yml` files. They will share the Containerfile and everything else, but things like packages declared in the recipe will be different between the images. For a more robust multibuild setup, you could consider forking from the [ublue-os/main](https://github.com/ublue-os/main/) repo, which was built from the purpose.
-
-In order to build multiple recipes, you need to declare each one below line ~33 in `build.yml`. The files should be in the root of the repository.
-
-Example: Adding a new recipe called `recipe-2.yml` (snippets from the `matrix` section of `build.yml`)
-
-Before:
-
-```yml
-matrix:
-  recipe:
-    - recipe.yml
-```
-
-After:
-
-```yml
-matrix:
-  recipe:
-    - recipe.yml
-    - recipe-2.yml
-```
-
-### [yafti](https://github.com/ublue-os/yafti/)
-
-`yafti` is the uBlue "first boot" installer. It shows up the first time a user logs into uBlue. By default, the menu also shows up again anytime the image's yafti configuration differs from the user's last encounter, so feel free to expand or modify your custom image's yafti configuration over time. Your users will then see the yafti menu again after the OS update, and will be given a chance to install any new additions.
-
-Its configuration can be found in `/usr/share/ublue-os/firstboot/yafti.yml` of the installed OS. It includes an optional selection of Flatpaks to install, along with a new group that's automatically added for all Flatpaks declared in `recipe.yml`. You can look at what's done in the `yafti.yml` config and modify it to your liking (in the repository, before building the image, since the installed system file is immutable).
-
-If you want to completely disable yafti, simply set the recipe's `firstboot.yafti` flag to `false`, which then removes all yafti-related files and configurations from your final image. The files in `usr/share/ublue-os/firstboot/` are responsible for automatically running yafti at login, and they will *only* be bundled in your image if `yafti` is enabled in your recipe!
-
 ## Installation
 
 > **Warning**
@@ -86,14 +13,14 @@ If you want to completely disable yafti, simply set the recipe's `firstboot.yaft
 
 To rebase an existing Silverblue/Kinoite installation to the latest build:
 
-```
+```bash
-sudo rpm-ostree rebase ostree-unverified-registry:ghcr.io/gmpinder/wunker-os:latest
+sudo rpm-ostree rebase ostree-unverified-registry:registry.gitlab.com/wunker-bunker/wunker-os/desktop:latest
 ```
 
 This repository builds date tags as well, so if you want to rebase to a particular day's build:
 
-```
+```bash
-sudo rpm-ostree rebase ostree-unverified-registry:ghcr.io/gmpinder/wunker-os:20230403
+sudo rpm-ostree rebase ostree-unverified-registry:registry.gitlab.com/wunker-bunker/wunker-os/desktop:20230403
 ```
 
 The `latest` tag will automatically point to the latest build. That build will still always use the Fedora version specified in `recipe.yml`, so you won't get accidentally updated to the next major version.
@@ -131,8 +58,10 @@ Check the [just website](https://just.systems) for tips on modifying and adding
 
 ## Verification
 
-These images are signed with sisgstore's [cosign](https://docs.sigstore.dev/cosign/overview/). You can verify the signature by downloading the `cosign.pub` key from this repo and running the following command:
+These images are signed with sisgstore's [cosign](https://docs.sigstore.dev/cosign/overview/). You can verify the signature by running the following command:
 
-    cosign verify --key cosign.pub ghcr.io/gmpinder/wunker-os
+```bash
+cosign verify --certificate-identity "https://gitlab.com/wunker-bunker/wunker-os//.gitlab-ci.yml@refs/heads/main" --certificate-oidc-issuer "https://gitlab.com" registry.gitlab.com/wunker-bunker/wunker-os/<VARIANT>:<TAG>
+```
 
-If you're forking this repo, the uBlue website has [instructions](https://ublue.it/making-your-own/) for setting up signing properly.
+Where `VARIANT` is the image from the recipe you choose and `TAG` is the version of the image.

cosign.pub

@@ -1,4 +0,0 @@
------BEGIN PUBLIC KEY-----
-MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEAyTphXdVzd8Yt5ZK+Hry/xPasjwJ
-EKXoUFZ4ZFvXFAmv9g4QACwx0fpzn8B6qG3b4yj0R0mmaD3bw9sIt8wUzA==
------END PUBLIC KEY-----

recipe-c.yml

@@ -0,0 +1,42 @@
+name: laptop-c
+base-image: ghcr.io/ublue-os/cinnamon-main
+fedora-version: 38
+description: The image of Wunker OS for a regular Cinnaomon user.
+scripts:
+  pre:
+    - autorun.sh
+  post:
+    - autorun.sh
+rpm:
+  # A list of urls of ".repo" files that should be added to your system.
+  # This is the proper way to add custom COPR repos to your image.
+  # Tip: Use `%FEDORA_VERSION%` instead of static Fedora version numbers,
+  # so that your repos automatically use your image's actual Fedora version,
+  # which greatly simplifies future maintenance of your custom recipe.
+  repos: []
+  install:
+    # Needed for yafti (the first boot installer). Remove if you're not using yafti.
+    - python3-pip
+    # GNOME's GTK4 theme, Libadwaita. Already included in Silverblue, but not
+    # other spins. You can remove if you aren't using yafti, but many native
+    # apps and binaries require it, so it's a good idea to always include it
+    # if you ever download or compile any custom software on your machine.
+    - libadwaita
+    - cronie
+    - fprintd
+    - fprintd-pam
+    - tlp
+    - powertop
+    - plasma-browser-integration
+  remove:
+    # Remove the native firefox (from Fedora) in favor of the Flatpak.
+    - firefox
+    - firefox-langpacks
+firstboot:
+  yafti: false
+  flatpaks:
+    - io.github.celluloid_player.Celluloid
+    - org.kde.
+    - com.discordapp.Discord
+    - com.nextcloud.desktopclient.nextcloud
+    - com.google.Chrome

recipe-desktop.yml

@@ -5,9 +5,13 @@ description: The image of Wunker OS for an Nvidia based desktop meant for gaming
 scripts:
   pre:
     - autorun.sh
+    - install-syncthing.sh
+    - setup-kubectl.sh
+    - setup-vscode.sh
   post:
     - autorun.sh
     - setup-desktop-audio.sh
+    - setup-selinux-dockersock.sh
 rpm:
   # A list of urls of ".repo" files that should be added to your system.
   # This is the proper way to add custom COPR repos to your image.
@@ -30,7 +34,7 @@ rpm:
     - docker
     - virt-manager
     - plasma-browser-integration
-    - 'gcc-c++'
+    - "gcc-c++"
     - id3v2
     - xinput
     - earthly

recipe-framework-13.yml

@@ -5,8 +5,12 @@ description: The image of Wunker OS for a Framework laptop. Make your own! https
 scripts:
   pre:
     - autorun.sh
+    - install-syncthing.sh
+    - setup-kubectl.sh
+    - setup-vscode.sh
   post:
     - autorun.sh
+    - setup-selinux-dockersock.sh
 rpm:
   # A list of urls of ".repo" files that should be added to your system.
   # This is the proper way to add custom COPR repos to your image.
@@ -33,7 +37,7 @@ rpm:
     - neofetch
     - virt-manager
     - plasma-browser-integration
-    - 'gcc-c++'
+    - "gcc-c++"
     - id3v2
     - xinput
     - earthly

usr-j/etc/tlp.conf

@@ -0,0 +1 @@
+PCIE_ASPM_ON_BAT=powersupersave