ceos/agama

Ladislav Slezák d4f44b8a8e

## Problem

The Live ISO sources are not maintained at GitHub, that makes the
development complicated:

- Cannot track the changes easily, working with history in OBS is
limited and more complicated than with Git
- Changing files in tarballs is difficult, you have to unpack it, modify
a file and then manually compress back with correct parameters
- Building the Live ISO locally is not trivial

## Solution

- Move the sources into the `/live` subdirectory
- Add GitHub action for automatic submission from `master` to the
[systemsmanagement:Agama:Staging](https://build.opensuse.org/project/show/systemsmanagement:Agama:Staging)
OBS project
- Allow running the ISO build locally via `make build`

## Changes

The individual files were not touched, I just copied them from the
current OBS project. I only moved the `fw_cleanup.rb` script to the
`/tmp` directory as the script is temporary and it is deleted at the end
of the ISO build.

- All Kiwi tarballs were unpacked to Git
- Simple `make` builds the sources to the `dist` subdirectory and builds
the tarballs
- The ISO can be built locally using `make build`
- Updated/extended the documentation in README.md (There are two
README.md files, the main in `/live` which documents the details and the
`/live/src/README.md` which is copied to OBS. Mostl importantly it says
"do not touch this in OBS, use GitHub".)

## Testing

- Tested manually
- The autosubmission works (see the [GitHub action
log](https://github.com/lslezak/agama/actions/runs/8780447151/job/24090382501))
- The built ISO works (tested in my [agama-live
branch](https://build.opensuse.org/package/show/home:lslezak:branches:systemsmanagement:Agama:Staging/agama-live)
project)
- Local build works as well

---------

Co-authored-by: Imobach González Sosa <igonzalezsosa@suse.com>

2024-04-23 10:03:43 +02:00

5.6 KiB

Raw Permalink Blame History

Packaging

This document summarizes the process we follow to build the Agama packages.

The Agama packages are available in two OBS projects:

systemsmanagement:Agama:Staging - contains the latest packages built from the master branch in Git. This project contains unstable development version of Agama. It is intended for development or testing new unfinished features.

These packages are automatically updated whenever the master branch is changed.
systemsmanagement:Agama:Devel - contains the latest released version of the Agama project. These packages should be more stable than in the Staging project. It is intended for testing.

These packages are updated automatically when a new version is released. See more detail in the bumping the version section below.

You can find more details the automatic OBS synchronization in the obs_integration.md file.

The process to build each package is slightly different depending on the technology we are using. While the Ruby-based one (rubygem-agama-yast) is built as any other YaST package, Agama server (agama), the CLI (agama-cli), and the web UI (cockpit-agama) rely on OBS source services.

Versioning Policy

We have decided to follow a single number schema: 1, 2, 3, etc. However, if we need to release a hot-fix, we might use a dotted version (e.g., 2.1). Moreover, all the components share the same version number. Releasing a new version implies that all of them get the new number, no matter if they contain changes or not.

Bumping the Version

In order to release a new version, we need to:

(cd service; bundle install) # Updates Gemfile.lock which is part of the repository
Add entries in the changes files. osc vc service/package osc vc rust/package osc vc web/package
Open a pull request to get these changes into the repository.
Once the pull request is merged, tag the repository with the proper version number. The processes to build the packages use this information to infer the version. You can set the tag with the rake tag command.
```
# automatic version, use the current <major version> + 1
rake tag
# manual version, useful for releasing a hot fix with a minor version
rake tag[42.1]
```
You need to push the tag to the server manually, see the rake tag output.

After creating the tag on the server the GitHub Actions will publish the packages in the systemsmanagement:Agama:Devel project and create submit requests to openSUSE Factory.

Building the Packages

The packages are updated automatically using the GitHub actions. Here are details for manual update.

Service

You can check the current package in systemsmanagement:Agama:Staging/rubygem-agama-yast.

Use rake to update the package in OBS as you would do with any other YaST package:

  cd service
  rake osc:commit

If you just want to build the package locally, run:

  rake osc:build

The Cockpit Module

The current package is systemsmanagement:Agama:Staging/cockpit-agama.

It relies on OBS Source Services to fetch the sources (including the dependencies), set the version and build the package. You can figure out most details by checking the _service file.

To manually update the package in the build service, you just need to type:

  sudo zypper install obs-service-node_modules
  osc service manualrun
  osc commit -m "Update sources"

If you want to build the package locally, just checkout (or branch) the package and run osc build.

The version number is inferred from the repository tags (see Releasing a new version): it uses the latest tag and the offset of the latest commit respect such a tag. (e.g. 2.1+42).

You can read more about the overall approach of this package in the following article: Git work flows in the upcoming 2.7 release.

Server and Command-line Interface

The current package is systemsmanagement:Agama:Staging/agama, which includes agama and agama-cli as a subpackage.

To manually update the package in the build service, run the following commands:

  sudo zypper install obs-service-cargo_vendor obs-service-cargo_audit   # from Factory or devel:languages:rust
  osc service manualrun
  osc addremove *
  osc commit -m "Update sources"