177ea1b08f
All calls to rpmmd.Depsolve() are now replaced with the equivalent call to solver.Depsolve() (or dnfjson.Depsolve() for one-off calls). Attached an unconfigured dnfjson.BaseSolver to all APIs and server configurations where rpmmd.RPMMD used to be. This BaseSolver instance loads the repository credentials from the system and carries the cache directory, much like the RPMMD field used to do. The BaseSolver is used to create an initialised (configured) solver with the platform variables (module platform ID, release ver, and arch) before running a Depsolve() or FetchMetadata() using the NewWithConfig() method. The FillDependencies() call in the modulesInfoHandler() of the weldr API has been replaced by a direct call to the Depsolve() function. This rpmmd function was only used here. Replacing the rpmmd.Depsolve() call in rpmmd.FillDependencies() with dnfjson.Depsolve() would have created an import cycle. The FillDependencies() function could have been moved to dnfjson, but since it's only used in one place, moving the one-line function body into the caller is ok. For testing: The mock-dnf-json is compiled to a temporary directory during test initialisation and used for each Depsolve() or FetchMetadata() call. The weldr API tests now use the mock dnfjson. Each rpmmd_mock.Fixture now also has a dnfjson_mock.ResponseGenerator. All API calls in the tests use the proper functions from dnfjson and only the dnf-json script is mocked. Because of this, some of the expected results in responses_test had to be changed to match correct behaviour: - The "builds" array of each package in the result of a module or project list is now sorted by version number (ascending) because we sort the package list in the result of dnfjson by NVR. - 'check_gpg: true' is added to the expected response of the depsolve test. The repository configs in the test weldr API specify 'CheckGPG: True', but the mock responses returned it as false, so the expected result didn't need to include it. Since now we're using the actual dnfjson code to convert the mock response to the internal structure, the repository settings are correctly used to set flag to true for each package associated with that repository. - The word "occurred" was mistyped as "occured" in rpmmd and is now fixed in dnfjson. |
||
|---|---|---|
| .devcontainer | ||
| .github | ||
| cmd | ||
| containers | ||
| distribution | ||
| docs | ||
| image-types | ||
| internal | ||
| repositories | ||
| schutzbot | ||
| templates | ||
| test | ||
| tools | ||
| vendor | ||
| .env | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .gitleaks.toml | ||
| .golangci.yml | ||
| .packit.yaml | ||
| .pylintrc | ||
| codecov.yml | ||
| CONTRIBUTING.md | ||
| DEPLOYING.md | ||
| dnf-json | ||
| docker-compose.yml | ||
| go.mod | ||
| go.sum | ||
| HACKING.md | ||
| krb5.conf | ||
| LICENSE | ||
| Makefile | ||
| osbuild-composer.spec | ||
| README.md | ||
| Schutzfile | ||
OSBuild Composer
Operating System Image Composition Services
The composer project is a set of HTTP services for composing operating system images. It builds on the pipeline execution engine of osbuild and defines its own class of images that it supports building.
Multiple APIs are available to access a composer service. This includes support for the lorax-composer API, and as such can serve as drop-in replacement for lorax-composer.
You can control a composer instance either directly via the provided APIs, or through higher-level user-interfaces from external projects. This, for instance, includes a Cockpit Module or using the composer-cli command-line tool.
Project
- Website: https://www.osbuild.org
- Bug Tracker: https://github.com/osbuild/osbuild-composer/issues
- IRC: #osbuild on Libera.Chat
- Changelog: https://github.com/osbuild/osbuild-composer/releases
Contributing
Please refer to the developer guide to learn about our workflow, code style and more.
About
Composer is a middleman between the workhorses from osbuild and the user-interfaces like cockpit-composer, composer-cli, or others. It defines a set of high-level image compositions that it supports building. Builds of these compositions can be requested via the different APIs of Composer, which will then translate the requests into pipeline-descriptions for osbuild. The pipeline output is then either provided back to the user, or uploaded to a user specified target.
The following image visualizes the overall architecture of the OSBuild infrastructure and the place that Composer takes:
Consult the osbuild-composer(7) man-page for an introduction into composer,
information on running your own composer instance, as well as details on the
provided infrastructure and services.
Requirements
The requirements for this project are:
osbuild >= 26systemd >= 244
At build-time, the following software is required:
go >= 1.16python-docutils >= 0.13krb5-develfor fedora/rhel orlibkrb5-devfor debian/ubuntu`
Build
The standard go package system is used. Consult upstream documentation for detailed help. In most situations the following commands are sufficient to build and install from source:
mkdir build
go build -o build ./...
The man-pages require python-docutils and can be built via:
make man
Repository:
- web: https://github.com/osbuild/osbuild-composer
- https:
https://github.com/osbuild/osbuild-composer.git - ssh:
git@github.com:osbuild/osbuild-composer.git
Pull request gating
Each pull request against osbuild-composer starts a series of automated
tests. Tests run via GitHub Actions and Jenkins. Each push to the pull request
will launch theses tests automatically.
Jenkins only tests pull requests from members of the osbuild organization in
GitHub. A member of the osbuild organization must say ok to test in a pull
request comment to approve testing. Anyone can ask for testing to run by
saying the bot's favorite word, schutzbot, in a pull request comment.
Testing will begin shortly after the comment is posted.
Test results in Jenkins are available by clicking the Details link on the right side of the Schutzbot check in the pull request page.
License:
- Apache-2.0
- See LICENSE file for details.