From 2d5bff32bb01ffb71fbe9a0fc45c06029d4a7c36 Mon Sep 17 00:00:00 2001 From: xynydev <60004820+xynydev@users.noreply.github.com> Date: Wed, 21 Feb 2024 12:57:10 +0200 Subject: [PATCH] chore: bring up-to-date with the main template, strip cruft from readmes --- .github/CODEOWNERS | 2 +- .github/semantic.yml | 2 - README.md | 73 ++----------------- config/README.md | 56 -------------- config/files/usr/.gitkeep | 0 .../usr/share/ublue-os/just/100-bling.just | 2 - .../usr/share/ublue-os/just/60-custom.just | 2 - config/recipe.yml | 44 +++++------ config/scripts/signing.sh | 30 -------- modules/.gitkeep | 0 modules/README.md | 46 ------------ 11 files changed, 25 insertions(+), 232 deletions(-) delete mode 100644 .github/semantic.yml delete mode 100644 config/README.md create mode 100644 config/files/usr/.gitkeep delete mode 100644 config/files/usr/share/ublue-os/just/100-bling.just delete mode 100644 config/files/usr/share/ublue-os/just/60-custom.just delete mode 100644 config/scripts/signing.sh create mode 100644 modules/.gitkeep delete mode 100644 modules/README.md diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index f6a87d2746..dc5d118768 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -1 +1 @@ -* @castrojo +* @xynydev diff --git a/.github/semantic.yml b/.github/semantic.yml deleted file mode 100644 index b5161df9de..0000000000 --- a/.github/semantic.yml +++ /dev/null @@ -1,2 +0,0 @@ -enabled: true -titleOnly: true diff --git a/README.md b/README.md index e63eda1dde..410b6371ef 100644 --- a/README.md +++ b/README.md @@ -1,46 +1,13 @@ -# Starting point +# Legacy template [![build-ublue](https://github.com/blue-build/legacy-template/actions/workflows/build.yml/badge.svg)](https://github.com/blue-build/legacy-template/actions/workflows/build.yml) -> **Warning** -> Startingpoint was recently rewritten, and this version is considered a "1.0" *semi-*stable release. -> There are breaking changes between this and the previous version. -> If you are merging changes from the previous (v0) version, please refer to [the heads-up blog post](https://universal-blue.org/blog/2023/09/02/startingpoint-rewrite-heads-up-what-you-need-to-know/). - -[![build-ublue](https://github.com/blue-build/legacy-template/actions/workflows/build.yml/badge.svg)](https://github.com/blue-build/legacy-template/actions/workflows/build.yml) - -This is a constantly updating template repository for creating [a native container image](https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable) designed to be customized however you want. GitHub will build your image for you, and then host it for you on [ghcr.io](https://github.com/features/packages). You then just tell your computer to boot off of that image. GitHub keeps 90 days worth image backups for you, thanks Microsoft! - -For more info, check out the [uBlue homepage](https://universal-blue.org/) and the [main uBlue repo](https://github.com/ublue-os/main/) - -## Getting started - -See the [Make Your Own-page in the documentation](https://universal-blue.org/tinker/make-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. - -After setup, it is recommended you update this README to describe your custom image. - -> **Note** -> Everywhere in this repository, make sure to replace `blue-build/legacy-template` with the details of your own repository. Unless you used one of the automatic repository setup tools 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 `config/recipe.yml`. It's documented using comments and should be pretty easy to understand. - -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 and will be applied to `/etc/` on boot. `config/files/usr` is copied into your image's `/usr` by default. If you need to add other directories in the root of your image, that can be done using the `files` module. Writing to `/var/` in the image builds of OSTree-based distros isn't supported and will not work, as that is a local user-managed directory! - -For more information about customization, see [the README in the config directory](config/README.md) - -Documentation around making custom images exists / should be written in two separate places: - -- [The Tinkerer's Guide on the website](https://universal-blue.org/tinker/make-your-own/) for general documentation around making custom images, best practices, tutorials, and so on. -- Inside this repository for documentation specific to the ins and outs of the template (like module documentation), and just some essential guidance on how to make custom images. +> **Warning** +> This repository was previously `ublue-os/startingpoint`, but has now been [moved to the BlueBuild organization](https://blue-build.org/blog/introducing-bluebuild/). New custom images should be created from the new [blue-build/template](https://github.com/blue-build/template), but this repository will be supported for the foreseeable future. +> Check out the [migration guide](https://blue-build.org/blog/introducing-bluebuild/#how-to-migrate) for migration instructions. ## Installation -> **Warning** > [This is an experimental feature](https://www.fedoraproject.org/wiki/Changes/OstreeNativeContainerStable) and should not be used in production, try it in a VM for a while! +> **Warning** +> [This is an experimental feature](https://www.fedoraproject.org/wiki/Changes/OstreeNativeContainerStable), try at your own discretion. To rebase an existing Silverblue/Kinoite installation to the latest build: @@ -61,14 +28,6 @@ To rebase an existing Silverblue/Kinoite installation to the latest build: systemctl reboot ``` -This repository builds date tags as well, so if you want to rebase to a particular day's build: - -``` -rpm-ostree rebase ostree-image-signed:docker://ghcr.io/blue-build/legacy-template:20230403 -``` - -This repository by default also supports signing. - 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. ## ISO @@ -77,24 +36,6 @@ This template includes a simple Github Action to build and release an ISO of you To run the action, simply edit the `boot_menu.yml` by changing all the references to startingpoint to your repository. This should trigger the action automatically. -The Action uses [isogenerator](https://github.com/ublue-os/isogenerator) and works in a similar manner to the official Universal Blue ISO. If you have any issues, you should first check [the documentation page on installation](https://universal-blue.org/installation/). The ISO is a netinstaller and should always pull the latest version of your image. +The Action currently uses [ublue-os/isogenerator-old](https://github.com/ublue-os/isogenerator-old) and works in a similar manner to the official Universal Blue ISO. If you have any issues, you should first check [the documentation page on installation](https://universal-blue.org/installation/). The ISO is a netinstaller and should always pull the latest version of your image. Note that this release-iso action is not a replacement for a full-blown release automation like [release-please](https://github.com/googleapis/release-please). - -## `just` - -The [`just`](https://just.systems/) command runner is included in all `ublue-os/main`-derived images. - -You need to have a `~/.justfile` with the following contents and `just` aliased to `just --unstable` (default in posix-compatible shells on ublue) to get started with just locally. - -``` -!include /usr/share/ublue-os/just/main.just -!include /usr/share/ublue-os/just/nvidia.just -!include /usr/share/ublue-os/just/custom.just -``` - -Then type `just` to list the just recipes available. - -The file `/usr/share/ublue-os/just/custom.just` is intended for the custom just commands (recipes) you wish to include in your image. By default, it includes the justfiles from [`ublue-os/bling`](https://github.com/ublue-os/bling), if you wish to disable that, you need to just remove the line that includes bling.just. - -See [the just-page in the Universal Blue documentation](https://universal-blue.org/guide/just/) for more information. diff --git a/config/README.md b/config/README.md deleted file mode 100644 index 53892ed462..0000000000 --- a/config/README.md +++ /dev/null @@ -1,56 +0,0 @@ -# Configuring your image - -The main file of your is *the recipe file*. You can have multiple recipe files, and the ones to build are declared in the matrix section of [build.yml](../.github/workflows/build.yml). - -## Basic options - -At the top of the recipe, there are four *mandatory* configuration options. - -`name:` is the name of the image that is used when rebasing to it. For example, the name "sapphire" would result in the final URL of the container being `ghcr.io//sapphire`. - -`description:` is a short description of your image that will be attached to your image's metadata. - -`base-image:` is the URL of the image your image will be built upon. - -`image-version:` is the version tag of the `base-image` that will be pulled. For example, Universal Blue's images build with Fedora version tags (`38`, `39`), with the `latest` tag for the latest major version, and [many other tags](https://github.com/ublue-os/main/pkgs/container/base-main/versions?filters%5Bversion_type%5D=tagged). - -## Modules - -The core of startingpoint's configuration is built around the idea of modules. Modules are scripts in the [`../modules`](../modules/) directory that you configure under `modules:` in the recipe. They are executed in order, and can run arbitrary shell commands and write any files. - -This repository fetches some useful default modules from [`ublue-os/bling`](https://github.com/ublue-os/bling/), like [`rpm-ostree`](https://universal-blue.org/tinker/modules/rpm-ostree) for pseudo-declarative package management, [`bling`](https://universal-blue.org/tinker/modules/bling) for pulling extra components from [`ublue-os/bling`](https://github.com/ublue-os/bling), and [`files`](https://universal-blue.org/tinker/modules/files) for copying files from the `config/files/` directory into your image. - -For a comprehensive list of modules, their in-depth documentation and example configuration, check out [the Modules page on the website](https://universal-blue.org/tinker/modules/). - -### Building multiple images and including module configuration from other files - -To build multiple images, you need to create another recipe.yml file, which you should name based on what kind of image you want it to build. Then, edit the [`build.yml`](../.github/workflows/build.yml) file. Inside the file, under `jobs: strategy: matrix:`, there's a list of recipe files to build images, which you need to add your new recipe file to. These should be paths to files inside the `config` directory. - -Module configuration can be included from other files using the `from-file` syntax. The value should be a path to a file inside the `config` directory. For example, the following snippet could be used to include the configuration for installing a set of packages common to multiple images. -```yaml -modules: - - from-file: common-packages.yml -``` -And inside config/common-packages.yml -```yaml -type: rpm-ostree -install: - - i3 - - dunst - - rofi - - kitty -``` -An external module can also include multiple modules. -```yaml -# config/common.yml -modules: - - type: files - files: - - usr: /usr - - type: rpm-ostree - install: - - i3 - - dunst - - rofi - - kitty -``` diff --git a/config/files/usr/.gitkeep b/config/files/usr/.gitkeep new file mode 100644 index 0000000000..e69de29bb2 diff --git a/config/files/usr/share/ublue-os/just/100-bling.just b/config/files/usr/share/ublue-os/just/100-bling.just deleted file mode 100644 index 9e3a89ba4b..0000000000 --- a/config/files/usr/share/ublue-os/just/100-bling.just +++ /dev/null @@ -1,2 +0,0 @@ -# this file is a placeholder, -# making changes here is not supported diff --git a/config/files/usr/share/ublue-os/just/60-custom.just b/config/files/usr/share/ublue-os/just/60-custom.just deleted file mode 100644 index 9fbf49282e..0000000000 --- a/config/files/usr/share/ublue-os/just/60-custom.just +++ /dev/null @@ -1,2 +0,0 @@ -import '100-bling.just' -# Include some of your custom scripts here! diff --git a/config/recipe.yml b/config/recipe.yml index cc14c1ba5a..7ce393ee09 100644 --- a/config/recipe.yml +++ b/config/recipe.yml @@ -1,7 +1,7 @@ # image will be published to ghcr.io// -name: startingpoint +name: template # description will be included in the image's metadata -description: A starting point for further customization of uBlue images. Make your own! https://ublue.it/making-your-own/ +description: This is my personal OS image. # the base image to build on top of (FROM) and the version tag to use base-image: ghcr.io/ublue-os/silverblue-main @@ -12,13 +12,10 @@ image-version: 39 # latest is also supported if you want new updates ASAP modules: - type: files files: - - usr: /usr # copy static configurations - # - # copies config/files/usr into your image's /usr - # - # configuration you wish to end up in /etc/ on the booted system - # should be added into /usr/etc/ as that is the proper "distro" - # config directory on ostree. Read more in the files module's README + - usr: + /usr # copies config/files/usr into your image's /usr. + # put configuration files you want in /etc/ on a booted system + # in /usr/etc/ in the image. read more in files module reference. - type: rpm-ostree repos: @@ -31,28 +28,21 @@ modules: - firefox-langpacks # langpacks needs to also be removed to prevent dependency problems - type: default-flatpaks - notify: true # Send notification after install/uninstall is finished (true/false) + notify: true # Send notification after install/uninstall is finished (true/false) system: # If no repo information is specified, Flathub will be used by default - repo-url: https://dl.flathub.org/repo/flathub.flatpakrepo - repo-name: flathub + # repo-url: https://dl.flathub.org/repo/flathub.flatpakrepo + # repo-name: flathub # repo-title: "Flathub (system-wide)" # Optional; this sets the remote's user-facing name in graphical frontends like GNOME Software install: - # - org.gnome.Loupe - # - one.ablaze.floorp//lightning # This is an example of flatpak which has multiple branches in selection (flatpak//branch). - # Flatpak runtimes are not supported (like org.winehq.Wine//stable-23.08). - # Only normal flatpak applications are (like Floorp Lightning web browser in this example). - # Multiple install of same flatpaks with different branches is not supported. + - org.mozilla.firefox + # - org.gnome.Loupe + # - one.ablaze.floorp//lightning # This is an example of flatpak which has multiple branches in selection (flatpak//branch). + # Flatpak runtimes are not supported (like org.winehq.Wine//stable-23.08), + # only normal flatpak applications are (like Floorp Lightning web browser in this example). + # Installing different branches of the same Flatpak is not supported. remove: # - org.gnome.eog - # - # A flatpak repo can also be added without having to install flatpaks, - # as long as one of the repo- fields is present - user: - repo-url: https://dl.flathub.org/repo/flathub.flatpakrepo - repo-name: flathub - - type: script - scripts: - # this sets up the proper policy & signing files for signed images to work - - signing.sh + - type: signing # this sets up the proper policy & signing files for signed images to work fully + diff --git a/config/scripts/signing.sh b/config/scripts/signing.sh deleted file mode 100644 index 16b0ea853b..0000000000 --- a/config/scripts/signing.sh +++ /dev/null @@ -1,30 +0,0 @@ -#!/usr/bin/env bash - -# Tell build process to exit if there are any errors. -set -oue pipefail - -echo "Setting up container signing in policy.json and cosign.yaml for $IMAGE_NAME" -echo "Registry to write: $IMAGE_REGISTRY" - -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_NAME"'": [ - { - "type": "sigstoreSigned", - "keyPath": "/usr/etc/pki/containers/'"$IMAGE_NAME"'.pub", - "signedIdentity": { - "type": "matchRepository" - } - } - ] - } -+ .' "$FILE" - -IMAGE_REF="ostree-image-signed:docker://$IMAGE_REGISTRY/$IMAGE_NAME" -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 diff --git a/modules/.gitkeep b/modules/.gitkeep new file mode 100644 index 0000000000..e69de29bb2 diff --git a/modules/README.md b/modules/README.md deleted file mode 100644 index 40a8bc8f73..0000000000 --- a/modules/README.md +++ /dev/null @@ -1,46 +0,0 @@ -# Making modules - -If you want to extend Startingpoint with custom functionality that requires configuration, you should create a module. Modules are scripts in the subdirectories of this directory. The `type:` key in the recipe.yml should be used as both the name of the folder and script, with the script having an additional `.sh` suffix. Creating a custom module with the same name as a default module will override it. - -Each module intended for public usage should include a `README.md` file inside it's directory with a short description of the module and documentation for each configuration option. - -Modules get only the configuration options given to them in the recipe.yml, not the configuration of other modules or any top-level keys. The configuration is given as the first argument as a single-line json string. You can check out the default modules for examples on how to parse such string using `yq` or `jq`. - -Additionally, each module has access to four environment variables, `CONFIG_DIRECTORY` pointing to the directory containing the confiuration files for the build (`/tmp/config`), `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. -# If you need to read from some other JSON string, just replace "$1" with "$VARNAME". -get_yaml_array OUTPUT_VAR_NAME '.yq.key.to.array[]' "$1" -for THING in "${OUTPUT_VAR_NAME[@]}"; do - echo "$THING" -done -``` - -All bash-based modules should start with the following lines to ensure the image builds fail on errors, and that the correct shell is used to run them. -```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..."