The messaging is not really part of compose settings. It is an
infrastructure part. As such, it should really be set up as part of
pungi invocation, not compose configuration.
The documentation is updated to reflect this. Some updates to the
documentation are done as well: listing messages about ISOs and minor
formatting updates.
The test_compose.sh script can now accept additional command line
options and pass them on to pungi-koji to simplify testing.
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
With this patch, Pungi can invoke an arbitrary command on various
moments of the compose process. The invoked command can the decide on
what message to send (and using what messaging system).
The actual command is specified in the config file.
There is a script provided that sends the messages via fedmsg.
The documentation is updated to have details about the new config option
as well as the interface for the messaging script.
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
The phase goes through all images declared in image manifest, computes
their checksums, stores them in appropriate files and updates the
manifest so that it includes the actual checksums.
The documentation contains details about new configuration options.
The test suite now needs Python's mock package.
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
CHANGE: Rename product_* config options to release_* for consistency with productmd.
ACTION: Rename product_name, product_short, product_version, product_is_layered to release_* in config files.
Rename //variant/product to //variant/release in variants XML.
CHANGE: createrepo_c is config option now defaults to True.
ACTION: You can safely remove 'createrepo_c = True' from config files.
Set 'createrepo_c = False' if you need legacy createrepo.
CHANGE: createrepo_checksum config option is now mandatory.
ACTION: Add 'createrepo_checksum = "sha256"' (or "sha") to config files.
Previous test data was insufficient for proper testing.
Test compose runs and depsolving tests require precisely
set NVRs, dependencies, sub-packages, etc.
Using rpmfluff for these would be an overkill, it's better
to create RPMs directly from specs.