Use go-vendor-tools to generate the license identifiers for our vendored
code. This initial commit does not yet apply the rest of go-vendor-tools
abilities to manage the vendoring itself.
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
This commit adds support for `--extra-artifacts=manifest`. If
that is given as part of the build an extra artifacts called
`<img-name>.osbuild-manifest.json` will be created in the
output directory.
Closes: https://github.com/osbuild/image-builder-cli/issues/42
The Go macros have a bunch of expectations about package names and
archive names. Let's keep the archive names with `-cli` in them to
appease them.
These can only be dropped after we change repositories around and thus
change the `goipath`; after which these can drop their `-cli`.
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
`image-builder` will be the main entrypoint into the Image Builder
stack. We will rename the repositories later on; but let's start
referring to it in its new official name.
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
This commit adds a new `--output-dir` option to override the
default output directory for the generated artifacts.
Note that this can also be used together with `manifest` when
extra artifacts (like the sbom) is requested.
This commit adds an option --extra-artifacts that can be
used to generate extra artifacts during the build or manifest
generation. Initially supported is `sbom` (but `manifest` is
planned too).
To use it run `--extra-artifacts=sbom` and it will generate
files like `centos-9-qcow2-x86_64.image-os.spdx.json` in
the output directory next to the generate runable artifact.
Closes: https://github.com/osbuild/image-builder-cli/issues/46
This commit adds a (smoke) integration test for librepo based
manifests. It needs a flanking test that also ensures that
--use-librepo really generates librepo sources.
This commit switches the default to librepo. We do not have many
users yet so this is a great place to test the new librepo
functionality. It also is much more stable for fedora/centos
systems that often have flaky mirrors.
This also bumps the minimum required version of osbuild.
This commit changes the signature of depsolve in `manifestgen`
to return the full `dnfjson.DepsolveResult`. This gives us
access to the sbom and also is a preparation for images PR#1142
where we will need this anyway.
This commit adds a new manifestOptions struct that is passed
to generateManifest. to cleanup the signature of generateManifest().
This can then also be used to carry a new e.g. `--rpmmd/--cachedir`
option.
This commit switches to the librepo enabled `images` library via:
```
go mod -replace github.com/osbuild/iamges=github.com/mvo5/images@librepo-sources-osbuild1974
```
which in turn needs osbuild PR#1974.
With that it then adds a new `--use-librepo` switch that will
enable librepo based downloading so that people can play with
the new backend.
Moves the blueprint argument to a named argument; freeing up space to
later be able to pass in multiple image types. This also slightly
simplifies the case where we're building without a blueprint available.
Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
This commit adds integration for the ostree options. It is modelled
loosely after weldr-client/composer-cli and the
```
start-ostree --{ref,parent,url}
```
and uses
```
--ostree-{ref,parent,url}
```
A simple smoke test is provided that uses fedora-iot. Ideas welcome
for an easier way :)
When depsolve is run it returns a list of packageSpecs and the
matching repository config. This repo config is different/distinct
from the repository config that is passed into depsolve via the
package sets or the repositories that are loaded via the
reporegistry and needs to be passed into `manifest.Serialize()`.
The key different is that the depsovle `repoConfig` contains
the repo.Id that match the packageSpec.RepoId. With those two
matching IDs we can use librepo (see osbuild PR#1974) to infere
what mirror to use for what package.
This commit now passes the correct repoConfig into
preManifest.Serialize() now.
No test (sorry!) as this is really hard to test in isolation, there
is nothing observable today from repoConfig and it is impossible
to add a "witness" pipelien that could check that the right argument
is passed in `pipeline.serializeStart()`. So until we refactor
images you will have to take my word for this (sorry again).
For releases this does not change anything, as the version
in the spec file is the same as the git tag. For
intermediate/tainted versions packer seems to patch the spec
file to the version given in `.packit.yaml`
(which is the latest git-tag), then the filename and version
would be inconsistent.
