refactor: clean up the template repo
many of these docs are now on the website, a lot of this is just baggage from startingpoint
This commit is contained in:
xynydev
parent
05b01dd282
commit
be99df8b6d
1
.gitignore
vendored
1
.gitignore
vendored
@ -1,3 +1,2 @@
|
||||
.idea
|
||||
cosign.key
|
||||
cosign.private
|
||||
|
||||
141
CONTRIBUTING.md
141
CONTRIBUTING.md
@ -1,141 +0,0 @@
|
||||
# Welcome to Universal Blue
|
||||
|
||||
Thanks for taking the time to look into helping out!
|
||||
All contributions are appreciated!
|
||||
Please refer to our [Code of Conduct](/CODE_OF_CONDUCT.md) while you're at it!
|
||||
|
||||
Feel free to report issues as you find them, and [helping others in the discussions]() is always appreciated.
|
||||
|
||||
# Contributing
|
||||
|
||||
All types of contributions are encouraged and valued. See the [Table of Contents](#table-of-contents) for different ways to help and details about how this project handles them. Please make sure to read the relevant section before making your contribution. It will make it a lot easier for us maintainers and smooth out the experience for all involved. The community looks forward to your contributions.
|
||||
|
||||
> And if you like the project, but just don't have time to contribute, that's fine. There are other easy ways to support the project and show your appreciation, which we would also be very happy about:
|
||||
> - Star the project
|
||||
> - Tweet about it
|
||||
> - Refer this project in your project's readme
|
||||
> - Mention the project at local meetups and tell your friends/colleagues
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Code of Conduct](#code-of-conduct)
|
||||
- [I Have a Question](#i-have-a-question)
|
||||
- [I Want To Contribute](#i-want-to-contribute)
|
||||
- [Reporting Bugs](#reporting-bugs)
|
||||
- [How to test incoming changes](#how-to-test-incoming-changes)
|
||||
- [Building Locally](#building-locally)
|
||||
- [Styleguides](#styleguides)
|
||||
- [Commit Messages](#commit-messages)
|
||||
- [Join The Project Team](#join-the-project-team)
|
||||
|
||||
## Code of Conduct
|
||||
|
||||
This project and everyone participating in it is governed by the
|
||||
[CONTRIBUTING.md Code of Conduct](/CODE_OF_CONDUCT.md).
|
||||
By participating, you are expected to uphold this code. Please report unacceptable behavior
|
||||
to jorge.castro@gmail.com
|
||||
|
||||
## I Have a Question
|
||||
|
||||
> If you want to ask a question, ask in the [discussion forum](https://github.com/orgs/ublue-os/discussions)
|
||||
|
||||
## I Want To Contribute
|
||||
|
||||
> ### Legal Notice
|
||||
> When contributing to this project, you must agree that you have authored 100% of the content, that you have the necessary rights to the content and that the content you contribute may be provided under the project license.
|
||||
|
||||
Generally speaking we try to follow the [Lazy Concensus](http://lazyconcens.us/) model of development to keep the builds healthy and ourselves happy.
|
||||
- If you're looking for concensus to make a decision post an issue for feedback and remember to account for timezones and weekends/holidays/work time.
|
||||
- We want people to be opinionated in their builds so we're more of a loose confederation of repos than a top-down org.
|
||||
- Try not to merge your own stuff, ask for a review. At some point when we have enough reviewers we'll be turning on branch protection.
|
||||
|
||||
### Reporting Bugs
|
||||
|
||||
#### Before Submitting a Bug Report
|
||||
|
||||
A good bug report should describe the issue in detail. Generally speaking:
|
||||
|
||||
- Make sure that you are using the latest version.
|
||||
- Remember that these are unofficial builds, it's usually prudent to investigate an issue before reporting it here or in Fedora!
|
||||
- Collect information about the bug:
|
||||
- `rpm-ostree status -v` usually helps
|
||||
- Image and Version
|
||||
- Possibly your input and the output
|
||||
- Can you reliably reproduce the issue? And can you also reproduce it with older versions?
|
||||
|
||||
### How to test incoming changes
|
||||
|
||||
One of the nice things about the image model is that we can generate an entire OS image for every change we want to commit, so this makes testing way easier than in the past. You can rebase to it, see if it works, and then move back. This also means we can increase the amount of testers!
|
||||
|
||||
We strive towards a model where proposed changes are more thoroughly reviewed and tested by the community. So here's how to do it. If you see a pull request that is opened up on an image you're following you can leave a review on how it's working for you. At the bottom of every PR you'll see something like this:
|
||||
|
||||
|
||||
|
||||
Click on "Add your review", and then you'll see this:
|
||||
|
||||
|
||||
|
||||
Don't worry, you can't mess anything up, all the merging and stuff will be done by the maintainer, what this does is lets us gather information in a more formal manner than just shoving everything in a forum thread. The more people are reviewing and testing images, the better off we'll be, especially for images that are new like Sericea.
|
||||
|
||||
At some point we'll have a bot that will leave you instructions on how to rebase to the image and all that stuff, but in the meantime we'll leave instructions manually.
|
||||
|
||||
Here's an example: https://github.com/ublue-os/nvidia/pull/49
|
||||
|
||||
## Building Locally
|
||||
|
||||
The minimum tools required are git and a working machine with podman enabled and configured.
|
||||
Building locally is much faster than building in GitHub and is a good way to move fast before pushing to a remote.
|
||||
|
||||
### Clone the repo you want
|
||||
|
||||
git clone https://github.com/ublue-os/base.git
|
||||
|
||||
### Build the image
|
||||
|
||||
First make sure you can build an existing image:
|
||||
|
||||
podman build . -t something
|
||||
|
||||
Then confirm your image built:
|
||||
|
||||
podman image ls
|
||||
|
||||
TODO: Set up and push to your own local registry
|
||||
|
||||
### Make your changes
|
||||
|
||||
This usually involved editing the `Containerfile`. Most techniques for building containers apply here, if you're new to containers using the term "Dockerfile" in your searches usually shows more results when you're searching for information.
|
||||
|
||||
Check out CoreOS's [layering examples](https://github.com/coreos/layering-examples) for more information on customizing.
|
||||
|
||||
### Reporting problems to Fedora
|
||||
|
||||
We endevaour to be a good partner for Fedora.
|
||||
|
||||
This project is consuming new features in Fedora and ostree, it is not uncommon to find an issue.
|
||||
Issues should be reported upstream, and in some cases we can help test and find fixes.
|
||||
Some of the issues you find may involve other dependencies in other projects, in those cases the Fedora team will tell you where to report the issue.
|
||||
|
||||
Upstream bug tracker: [https://github.com/fedora-silverblue/issue-tracker/issues](https://github.com/fedora-silverblue/issue-tracker/issues)
|
||||
|
||||
## Styleguides
|
||||
### Commit Messages
|
||||
|
||||
We use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) and enforce them with a bot to keep the changelogs tidy:
|
||||
|
||||
```
|
||||
chore: add Oyster build script
|
||||
docs: explain hat wobble
|
||||
feat: add beta sequence
|
||||
fix: remove broken confirmation message
|
||||
refactor: share logic between 4d3d3d3 and flarhgunnstow
|
||||
style: convert tabs to spaces
|
||||
test: ensure Tayne retains clothing
|
||||
```
|
||||
|
||||
## Join The Project Team
|
||||
|
||||
If you're interested in _maintaining_ something then let us know!
|
||||
|
||||
## Attribution
|
||||
This guide is based on the **contributing.md**. [Make your own](https://contributing.md/)!
|
||||
44
README.md
44
README.md
@ -1,31 +1,15 @@
|
||||
# BlueBuild Template
|
||||
|
||||
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 [BlueBuild homepage](https://blue-build.org/) and the [BlueBuild CLI](https://github.com/blue-build/cli)
|
||||
|
||||
## Getting started
|
||||
|
||||
See the [BlueBuild docs](https://blue-build.org/learn/getting-started) 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.
|
||||
See the [BlueBuild docs](https://blue-build.org/how-to/setup/) for quick setup instructions for setting up your own repository based on this template.
|
||||
|
||||
After setup, it is recommended you update this README to describe your custom image.
|
||||
|
||||
## 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)
|
||||
|
||||
## 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!
|
||||
|
||||
To rebase an existing Silverblue/Kinoite installation to the latest build:
|
||||
To rebase an existing atomic Fedora installation to the latest build:
|
||||
|
||||
- First rebase to the unsigned image, to get the proper signing keys and policies installed:
|
||||
```
|
||||
@ -44,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/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
|
||||
@ -63,19 +39,3 @@ To run the action, simply edit the `boot_menu.yml` by changing all the reference
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
@ -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/<yourusername>/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
|
||||
```
|
||||
@ -1,2 +0,0 @@
|
||||
# this file is a placeholder,
|
||||
# making changes here is not supported
|
||||
@ -1,7 +1,7 @@
|
||||
# image will be published to ghcr.io/<user>/<name>
|
||||
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
|
||||
#
|
||||
- usr: /usr # 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
|
||||
# config directory on ostree. Read more in the files module's documentation
|
||||
|
||||
- type: rpm-ostree
|
||||
repos:
|
||||
@ -31,26 +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:
|
||||
|
||||
0
modules/.gitkeep
Normal file
0
modules/.gitkeep
Normal file
@ -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..."
|
||||
Loading…
x
Reference in New Issue
Block a user