The `cloudbuildResourcesFromBuildLog()` function from the internal GCP package could cause panic while parsing Build job log which failed early and didn't create any Compute Engine resources. The function relied on the `Regexp.FindStringSubmatch()` method to always return a match while being used on the build log. Accessing a member of a nil slice would cause a panic in `osbuild-worker`, such as: Stack trace of thread 185316: #0 0x0000564e5393b5e1 runtime.raise (osbuild-worker) #1 0x0000564e5391fa1e runtime.sigfwdgo (osbuild-worker) #2 0x0000564e5391e354 runtime.sigtrampgo (osbuild-worker) #3 0x0000564e5393b953 runtime.sigtramp (osbuild-worker) #4 0x00007f37e98e3b20 __restore_rt (libpthread.so.0) #5 0x0000564e5393b5e1 runtime.raise (osbuild-worker) #6 0x0000564e5391f5ea runtime.crash (osbuild-worker) #7 0x0000564e53909306 runtime.fatalpanic (osbuild-worker) #8 0x0000564e53908ca1 runtime.gopanic (osbuild-worker) #9 0x0000564e53906b65 runtime.goPanicIndex (osbuild-worker) #10 0x0000564e5420b36e github.com/osbuild/osbuild-composer/internal/cloud/gcp.cloudbuildResourcesFromBuildLog (osbuild-worker) #11 0x0000564e54209ebb github.com/osbuild/osbuild-composer/internal/cloud/gcp.(*GCP).CloudbuildBuildCleanup (osbuild-worker) #12 0x0000564e54b05a9b main.(*OSBuildJobImpl).Run (osbuild-worker) #13 0x0000564e54b08854 main.main (osbuild-worker) #14 0x0000564e5390b722 runtime.main (osbuild-worker) #15 0x0000564e53939a11 runtime.goexit (osbuild-worker) Add a unit test testing this scenario. Make the `cloudbuildResourcesFromBuildLog()` function more robust and not blindly expect to find matches in the build log. As a result the `cloudbuildBuildResources` struct instance returned from the function may be empty. Subsequently make sure that the `CloudbuildBuildCleanup()` method handles an empty `cloudbuildBuildResources` instance correctly. Specifically the `storageCacheDir.bucket` may be an empty string and thus won't exist. Ensure that this does not result in infinite loop by checking for `storage.ErrBucketNotExist` while iterating the bucket objects. Signed-off-by: Tomas Hozza <thozza@redhat.com> |
||
|---|---|---|
| .github | ||
| cmd | ||
| containers/osbuild-composer | ||
| distribution | ||
| docs | ||
| image-types | ||
| internal | ||
| repositories | ||
| schutzbot | ||
| test | ||
| tools | ||
| vendor | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .golangci.yml | ||
| codecov.yml | ||
| CONTRIBUTING.md | ||
| DEPLOYING.md | ||
| dnf-json | ||
| go.mod | ||
| go.sum | ||
| HACKING.md | ||
| krb5.conf | ||
| LICENSE | ||
| Makefile | ||
| NEWS.md | ||
| 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
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.14python-docutils >= 0.13
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.