We originally added semi-generic parameter passing for OVA support and
then overloaded it for Vagrant support, before breaking that back out
as specific image types.
This change adds a fairly generic mechanism for parameter passthrough
to plugins and the base builder that does not require patching the
builder and CLI each time a new class of parameter is added to Factory.
The immediate reason for doing this is to expose the Docker plugin's
ability to set custom labels, environments and commands, but it is
likely to be useful for other things in the future.
Citing from reindent docs:
Change Python (.py) files to use 4-space indents and no hard tab
characters. Also trim excess spaces and tabs from ends of lines, and
remove empty lines at the end of files. Also ensure the last line
ends with a newline.
Citing from PEP 8:
Use 4 spaces per indentation level.
Python 2 code indented with a mixture of tabs and spaces should be
converted to using spaces exclusively.
Don't write string literals that rely on significant trailing
whitespace. Such trailing whitespace is visually indistinguishable
and some editors (or more recently, reindent.py) will trim them.
Also PyLint recommends not to have trailing whitespace on any line.
We originally added Vagrant support by tweaking options sent
to the existing RHEV-M and vSphere OVA generation code. This was
a bit of a hack and resulted in confusing filenames.
This adds "vagrant-libvirt" and "vagrant-virtualbox" image types,
passes in the correct options to Image Factory and produces output
files with the conventional ".box" extension and more descriptive
and less confusing vagrant name suffixes.
The resolve-plugins goal is not often used during upstream development, and it
causes unnecessary dependencies to be downloaded and builds to take longer.
The data collected during that step hasn't been used for anything, so it is
safe to remove. All dependencies downloaded during the build will still be
recorded after the deploy goal is completed.
-Dfoo and -Dfoo= mean different things to the JVM, so make sure the format of the parameter on the command-line is carried through to the mvn invocation.
This creates a new koji task type and CLI option called
image-build-indirection
This task builds an output image using the Image Factory "Indirection"
plugin
It takes as its input two already built images, either as explicit
task numbers of NVR and arch. It also requires a modified TDL
file as described in the Image Factory source.
The two input images are referred to as the base_image, which contains
content to be turned into another output image, and the utility_image,
which is a full system that will be booted to do the transformation.
The TDL, or "indirection_template" describes the tasks to be performed
inside of the running base image to generate the output.
This feature has the potential to build all of the following types of
images:
Disk Image Builder disk images, built with DIB elements using DIB itself
Live ISO images created using Live Media Creator
Docker layered images built using an arbitrary Docker version and a
Docker base image already built inside of koji
The config file tries to explain to the admin how to specify
allowed_scms, but one option (source_cmd) was missing.
This just reuses the wording of the docstring from the function parsing
this option, providing a complete documentation to admins when they read
the config file.
as we publish the raw files on the mirrors we want to be able to request
xz compressed versions of theraw image.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
The new "koji chainmaven" command allows Maven builds to be run in depdencency order,
without needing to wait for repo regens. A config file specifies the parameters and
dependencies for each build in the sequence. Each build is launched as soon as all
dependent builds are complete, and is able to reference the output of all of its
dependencies. If the build source URL and parameters match the latest build of the
same package in the destination tag, the build will not be re-run.
