1PUNGI(1) Pungi PUNGI(1)
2
6 pungi - Pungi Documentation
7 Contents:
9
11 [image: Pungi Logo] [image]
12 Pungi is a distribution compose tool.
14 Composes are release snapshots that contain release deliverables such
16 as:
17 · installation trees
19 · RPMs
21 · repodata
23 · comps
25 · (bootable) ISOs
27 · kickstart trees
29 · anaconda images
31 · images for PXE boot
33 Tool overview
35 Pungi consists of multiple separate executables backed by a common
36 library.
37 The main entry-point is the pungi-koji script. It loads the compose
39 configuration and kicks off the process. Composing itself is done in
40 phases. Each phase is responsible for generating some artifacts on
41 disk and updating the compose object that is threaded through all the
42 phases.
43 Pungi itself does not actually do that much. Most of the actual work is
45 delegated to separate executables. Pungi just makes sure that all the
46 commands are invoked in the appropriate order and with correct argu‐
47 ments. It also moves the artifacts to correct locations.
48 The executable name pungi-koji comes from the fact that most of those
50 separate executables submit tasks to Koji that does the actual work in
51 an auditable way.
52 However unlike doing everything manually in Koji, Pungi will make sure
54 you are building all images from the same package set, and will produce
55 even deliverables that Koji can not create like YUM repos and installer
56 ISOs.
57 Links
59 · Upstream GIT: https://pagure.io/pungi/
60 · Issue tracker: https://pagure.io/pungi/issues
62 · Questions can be asked on #fedora-releng IRC channel on FreeNode
64 Origin of name
66 The name Pungi comes from the instrument used to charm snakes. Anaconda
67 being the software Pungi was manipulating, and anaconda being a snake,
68 led to the referential naming.
69 The first name, which was suggested by Seth Vidal, was FIST, Fedora
71 Installation <Something> Tool. That name was quickly discarded and
72 replaced with Pungi.
73 There was also a bit of an inside joke that when said aloud, it could
75 sound like punji, which is a sharpened stick at the bottom of a trap.
76 Kind of like software…
77
79 Each invocation of pungi-koji consists of a set of phases. [image:
80 phase diagram] [image]
81 Most of the phases run sequentially (left-to-right in the diagram), but
83 there are use cases where multiple phases run in parallel. This happens
84 for phases whose main point is to wait for a Koji task to finish.
85 Init
87 The first phase to ever run. Can not be skipped. It prepares the comps
88 files for variants (by filtering out groups and packages that should
89 not be there). See comps for details about how this is done.
90 Pkgset
92 This phase loads a set of packages that should be composed. It has two
93 separate results: it prepares repos with packages in work/ directory
94 (one per arch) for further processing, and it returns a data structure
95 with mapping of packages to architectures.
96 Buildinstall
98 Spawns a bunch of threads, each of which runs either lorax or buildin‐
99 stall command (the latter coming from anaconda package). The commands
100 create boot.iso and other boot configuration files. The image is
101 finally linked into the compose/ directory as netinstall media.
102 The created images are also needed for creating live media or other
104 images in later phases.
105 With lorax this phase runs one task per variant.arch combination. For
107 buildinstall command there is only one task per architecture and prod‐
108 uct.img should be used to customize the results.
109 Gather
111 This phase uses data collected by pkgset phase and figures out what
112 packages should be in each variant. The basic mapping can come from
113 comps file, a JSON mapping or additional_packages config option. This
114 inputs can then be enriched by adding all dependencies. See gathering
115 for details.
116 Once the mapping is finalized, the packages are linked to appropriate
118 places and the rpms.json manifest is created.
119 ExtraFiles
121 This phase collects extra files from the configuration and copies them
122 to the compose directory. The files are described by a JSON file in the
123 compose subtree where the files are copied. This metadata is meant to
124 be distributed with the data (on ISO images).
125 Createrepo
127 This phase creates RPM repositories for each variant.arch tree. It is
128 actually reading the rpms.json manifest to figure out which packages
129 should be included.
130 OSTree
132 Updates an ostree repository with a new commit with packages from the
133 compose. The repository lives outside of the compose and is updated
134 immediately. If the compose fails in a later stage, the commit will not
135 be reverted.
136 Implementation wise, this phase runs rpm-ostree command in Koji runroot
138 (to allow running on different arches).
139 Createiso
141 Generates ISO files and accumulates enough metadata to be able to cre‐
142 ate image.json manifest. The file is however not created in this phase,
143 instead it is dumped in the pungi-koji script itself.
144 The files include a repository with all RPMs from the variant. There
146 will be multiple images if the packages do not fit on a single image.
147 The image will be bootable if buildinstall phase is enabled and the
149 packages fit on a single image.
150 There can also be images with source repositories. These are never
152 bootable.
153 ExtraIsos
155 This phase is very similar to createiso, except it combines content
156 from multiple variants onto a single image. Packages, repodata and
157 extra files from each configured variant are put into a subdirectory.
158 Additional extra files can be put into top level of the image. The
159 image will be bootable if the main variant is bootable.
160 LiveImages, LiveMedia
162 Creates media in Koji with koji spin-livecd, koji spin-appliance or
163 koji spin-livemedia command. When the media are finished, the images
164 are copied into the compose/ directory and metadata for images is
165 updated.
166 ImageBuild
168 This phase wraps up koji image-build. It also updates the metadata
169 ultimately responsible for images.json manifest.
170 OSBS
172 This phase builds docker base images in OSBS.
173 The finished images are available in registry provided by OSBS, but not
175 downloaded directly into the compose. The is metadata about the created
176 image in compose/metadata/osbs.json.
177 OSTreeInstaller
179 Creates bootable media that carry an ostree repository as a payload.
180 These images are created by running lorax with special templates. Again
181 it runs in Koji runroot.
182 ImageChecksum
184 Responsible for generating checksums for the images. The checksums are
185 stored in image manifest as well as files on disk. The list of images
186 to be processed is obtained from the image manifest. This way all
187 images will get the same checksums irrespective of the phase that cre‐
188 ated them.
189 Test
191 This phase is supposed to run some sanity checks on the finished com‐
192 pose.
193 The first test is to run repoclosure on each repository. By default
195 errors are only reported in the log, the compose will still be consid‐
196 ered a success. The actual error has to be looked up in the compose
197 logs directory. Configuration allows customizing this.
198 The other test is to check all images listed the metadata and verify
200 that they look sane. For ISO files headers are checked to verify the
201 format is correct, and for bootable media a check is run to verify they
202 have properties that allow booting.
203
205 The configuration file parser is provided by kobo
206 The file follows a Python-like format. It consists of a sequence of
208 variables that have a value assigned to them.
209 variable = value
211 The variable names must follow the same convention as Python code:
213 start with a letter and consist of letters, digits and underscores
214 only.
215 The values can be either an integer, float, boolean (True or False), a
217 string or None. Strings must be enclosed in either single or double
218 quotes.
219 Complex types are supported as well.
221 A list is enclosed in square brackets and items are separated with com‐
223 mas. There can be a comma after the last item as well.
224 a_list = [1,
226 2,
227 3,
228 ]
229 A tuple works like a list, but is enclosed in parenthesis.
231 a_tuple = (1, "one")
233 A dictionary is wrapped in brackets, and consists of key: value pairs
235 separated by commas. The keys can only be formed from basic types (int,
236 float, string).
237 a_dict = {
239 'foo': 'bar',
240 1: None
241 }
242 The value assigned to a variable can also be taken from another vari‐
244 able.
245 one = 1
247 another = one
248 Anything on a line after a # symbol is ignored and functions as a com‐
250 ment.
251 Importing other files
253 It is possible to include another configuration file. The files are
254 looked up relative to the currently processed file.
255 The general structure of import is:
257 from FILENAME import WHAT
259 The FILENAME should be just the base name of the file without extension
261 (which must be .conf). WHAT can either be a comma separated list of
262 variables or *.
263 # Opens constants.conf and brings PI and E into current scope.
265 from constants import PI, E
266 # Opens common.conf and brings everything defined in that file into current
268 # file as well.
269 from common import *
270 NOTE:
272 Pungi will copy the configuration file given on command line into
273 the logs/ directory. Only this single file will be copied, not any
274 included ones. (Copying included files requires a fix in kobo
275 library.)
276 The JSON-formatted dump of configuration is correct though.
278 Formatting strings
280 String interpolation is available as well. It uses a %-encoded format.
281 See Python documentation for more details.
282 joined = "%s %s" % (var_a, var_b)
284 a_dict = {
286 "fst": 1,
287 "snd": 2,
288 }
289 another = "%(fst)s %(snd)s" % a_dict
290
292 Please read productmd documentation for terminology and other release
293 and compose related details.
294 Minimal Config Example
296 # RELEASE
297 release_name = "Fedora"
298 release_short = "Fedora"
299 release_version = "23"
300 # GENERAL SETTINGS
302 comps_file = "comps-f23.xml"
303 variants_file = "variants-f23.xml"
304 module_defaults_dir = "module_defaults"
305 # KOJI
307 koji_profile = "koji"
308 runroot = False
309 # PKGSET
311 sigkeys = [None]
312 pkgset_source = "koji"
313 pkgset_koji_tag = "f23"
314 # CREATEREPO
316 createrepo_checksum = "sha256"
317 # GATHER
319 gather_method = "deps"
320 greedy_method = "build"
321 check_deps = False
322 # BUILDINSTALL
324 buildinstall_method = "lorax"
325 Release
327 Following mandatory options describe a release.
328 Options
330 release_name [mandatory]
331 (str) – release name
332 release_short [mandatory]
334 (str) – release short name, without spaces and special charac‐
335 ters
336 release_version [mandatory]
338 (str) – release version
339 release_type = “ga” (str) – release type, for example ga,
341 updates or updates-testing. See list of all valid values in pro‐
342 ductmd documentation.
343 release_internal = False
345 (bool) – whether the compose is meant for public consumption
346 treeinfo_version
348 (str) Version to display in .treeinfo files. If not configured,
349 the value from release_version will be used.
350 Example
352 release_name = "Fedora"
353 release_short = "Fedora"
354 release_version = "23"
355 # release_type = "ga"
356 Base Product
358 Base product options are optional and we need to them only if we’re
359 composing a layered product built on another (base) product.
360 Options
362 base_product_name
363 (str) – base product name
364 base_product_short
366 (str) – base product short name, without spaces and special
367 characters
368 base_product_version
370 (str) – base product major version
371 base_product_type = “ga”
373 (str) – base product type, “ga”, “updates” etc., for full list
374 see documentation of productmd.
375 Example
377 release_name = "RPM Fusion"
378 release_short = "rf"
379 release_version = "23.0"
380 base_product_name = "Fedora"
382 base_product_short = "Fedora"
383 base_product_version = "23"
384 General Settings
386 Options
387 comps_file [mandatory]
388 (scm_dict, str or None) – reference to comps XML file with
389 installation groups
390 variants_file [mandatory]
392 (scm_dict or str) – reference to variants XML file that defines
393 release variants and architectures
394 module_defaults_dir [optional]
396 (scm_dict or str) – reference the module defaults directory con‐
397 taining modulemd-defaults YAML documents
398 failable_deliverables [optional]
400 (list) – list which deliverables on which variant and architec‐
401 ture can fail and not abort the whole compose. This only applies
402 to buildinstall and iso parts. All other artifacts can be con‐
403 figured in their respective part of configuration.
404 Please note that * as a wildcard matches all architectures but
406 src.
407 comps_filter_environments [optional]
409 (bool) – When set to False, the comps files for variants will
410 not have their environments filtered to match the variant.
411 tree_arches
413 ([str]) – list of architectures which should be included; if
414 undefined, all architectures from variants.xml will be included
415 tree_variants
417 ([str]) – list of variants which should be included; if unde‐
418 fined, all variants from variants.xml will be included
419 repoclosure_strictness
421 (list) – variant/arch mapping describing how repoclosure should
422 run. Possible values are
423 · off – do not run repoclosure
425 · lenient – (default) run repoclosure and write results to
427 logs, but detected errors are only reported in logs
428 · fatal – abort compose when any issue is detected
430 When multiple blocks in the mapping match a variant/arch combi‐
432 nation, the last value will win.
433 repoclosure_backend
435 (str) – Select which tool should be used to run repoclosure over
436 created repositories. By default yum is used, but you can switch
437 to dnf. Please note that when dnf is used, the build dependen‐
438 cies check is skipped. On Python 3, only dnf backend is avail‐
439 able.
440 compose_type
442 (str) – Allows to set default compose type. Type set via a com‐
443 mand-line option overwrites this.
444 Example
446 comps_file = {
447 "scm": "git",
448 "repo": "https://git.fedorahosted.org/git/comps.git",
449 "branch": None,
450 "file": "comps-f23.xml.in",
451 }
452 variants_file = {
454 "scm": "git",
455 "repo": "https://pagure.io/pungi-fedora.git ",
456 "branch": None,
457 "file": "variants-fedora.xml",
458 }
459 failable_deliverables = [
461 ('^.*$', {
462 # Buildinstall can fail on any variant and any arch
463 '*': ['buildinstall'],
464 'src': ['buildinstall'],
465 # Nothing on i386 blocks the compose
466 'i386': ['buildinstall', 'iso', 'live'],
467 })
468 ]
469 tree_arches = ["x86_64"]
471 tree_variants = ["Server"]
472 repoclosure_strictness = [
474 # Make repoclosure failures fatal for compose on all variants …
475 ('^.*$', {'*': 'fatal'}),
476 # … except for Everything where it should not run at all.
477 ('^Everything$', {'*': 'off'})
478 ]
479 Image Naming
481 Both image name and volume id are generated based on the configuration.
482 Since the volume id is limited to 32 characters, there are more set‐
483 tings available. The process for generating volume id is to get a list
484 of possible formats and try them sequentially until one fits in the
485 length limit. If substitutions are configured, each attempted volume id
486 will be modified by it.
487 For layered products, the candidate formats are first image_volid_lay‐
489 ered_product_formats followed by image_volid_formats. Otherwise, only
490 image_volid_formats are tried.
491 If no format matches the length limit, an error will be reported and
493 compose aborted.
494 Options
496 There a couple common format specifiers available for both the options:
497 · compose_id
499 · release_short
501 · version
503 · date
505 · respin
507 · type
509 · type_suffix
511 · label
513 · label_major_version
515 · variant
517 · arch
519 · disc_type
521 image_name_format [optional]
523 (str|dict) – Python’s format string to serve as template for
524 image names. The value can also be a dict mapping variant UID
525 regexes to the format string. The pattern should not overlap,
526 otherwise it is undefined which one will be used.
527 This format will be used for all phases generating images. Cur‐
529 rently that means createiso, live_images and buildinstall.
530 Available extra keys are:
532 · disc_num
534 · suffix
536 image_volid_formats [optional]
538 (list) – A list of format strings for generating volume id.
539 The extra available keys are:
541 · base_product_short
543 · base_product_version
545 image_volid_layered_product_formats [optional]
547 (list) – A list of format strings for generating volume id for
548 layered products. The keys available are the same as for
549 image_volid_formats.
550 restricted_volid = False
552 (bool) – New versions of lorax replace all non-alphanumerical
553 characters with dashes (underscores are preserved). This option
554 will mimic similar behaviour in Pungi.
555 volume_id_substitutions [optional]
557 (dict) – A mapping of string replacements to shorten the volume
558 id.
559 disc_types [optional]
561 (dict) – A mapping for customizing disc_type used in image
562 names.
563 Available keys are:
565 · boot – for boot.iso images created in buildinstall
567 phase
568 · live – for images created by live_images phase
570 · dvd – for images created by createiso phase
572 · ostree – for ostree installer images
574 Default values are the same as the keys.
576 Example
578 # Image name respecting Fedora's image naming policy
579 image_name_format = "%(release_short)s-%(variant)s-%(disc_type)s-%(arch)s-%(version)s%(suffix)s"
580 # Use the same format for volume id
581 image_volid_formats = [
582 "%(release_short)s-%(variant)s-%(disc_type)s-%(arch)s-%(version)s"
583 ]
584 # No special handling for layered products, use same format as for regular images
585 image_volid_layered_product_formats = []
586 # Replace "Cloud" with "C" in volume id etc.
587 volume_id_substitutions = {
588 'Cloud': 'C',
589 'Alpha': 'A',
590 'Beta': 'B',
591 'TC': 'T',
592 }
593 disc_types = {
595 'boot': 'netinst',
596 'live': 'Live',
597 'dvd': 'DVD',
598 }
599 Signing
601 If you want to sign deliverables generated during pungi run like RPM
602 wrapped images. You must provide few configuration options:
603 signing_command [optional]
605 (str) – Command that will be run with a koji build as a single
606 argument. This command must not require any user interaction.
607 If you need to pass a password for a signing key to the command,
608 do this via command line option of the command and use string
609 formatting syntax %(signing_key_password)s. (See sign‐
610 ing_key_password_file).
611 signing_key_id [optional]
613 (str) – ID of the key that will be used for the signing. This
614 ID will be used when crafting koji paths to signed files (kojip‐
615 kgs.fedoraproject.org/pack‐
616 ages/NAME/VER/REL/data/signed/KEYID/..).
617 signing_key_password_file [optional]
619 (str) – Path to a file with password that will be formatted into
620 signing_command string via %(signing_key_password)s string for‐
621 mat syntax (if used). Because pungi config is usualy stored in
622 git and is part of compose logs we don’t want password to be
623 included directly in the config. Note: If - string is used
624 instead of a filename, then you will be asked for the password
625 interactivelly right after pungi starts.
626 Example
628 signing_command = '~/git/releng/scripts/sigulsign_unsigned.py -vv --password=%(signing_key_password)s fedora-24'
629 signing_key_id = '81b46521'
630 signing_key_password_file = '~/password_for_fedora-24_key'
631 Git URLs
633 In multiple places the config requires URL of a Git repository to down‐
634 load some file from. This URL is passed on to Koji. It is possible to
635 specify which commit to use using this syntax:
636 git://git.example.com/git/repo-name.git?#<rev_spec>
638 The <rev_spec> pattern can be replaced with actual commit SHA, a tag
640 name, HEAD to indicate that tip of default branch should be used or
641 origin/<branch_name> to use tip of arbitrary branch.
642 If the URL specifies a branch or HEAD, Pungi will replace it with the
644 actual commit SHA. This will later show up in Koji tasks and help with
645 tracing what particular inputs were used.
646 NOTE:
648 The origin must be specified because of the way Koji works with the
649 repository. It will clone the repository then switch to requested
650 state with git reset --hard REF. Since no local branches are cre‐
651 ated, we need to use full specification including the name of the
652 remote.
653 Createrepo Settings
655 Options
656 createrepo_checksum
657 (str) – specify checksum type for createrepo; expected values:
658 sha512, sha256, sha. Defaults to sha256.
659 createrepo_c = True
661 (bool) – use createrepo_c (True) or legacy createrepo (False)
662 createrepo_deltas = False
664 (list) – generate delta RPMs against an older compose. This
665 needs to be used together with --old-composes command line argu‐
666 ment. The value should be a mapping of variants and architec‐
667 tures that should enable creating delta RPMs. Source and debug‐
668 info repos never have deltas.
669 createrepo_use_xz = False
671 (bool) – whether to pass --xz to the createrepo command. This
672 will cause the SQLite databases to be compressed with xz.
673 createrepo_num_threads
675 (int) – how many concurrent createrepo process to run. The
676 default is to use one thread per CPU available on the machine.
677 createrepo_num_workers
679 (int) – how many concurrent createrepo workers to run. Value
680 defaults to 3.
681 createrepo_database
683 (bool) – whether to create SQLite database as part of the repo‐
684 data. This is only useful as an optimization for clients using
685 Yum to consume to the repo. Default value depends on gather
686 backend. For DNF it’s turned off, for Yum the default is True.
687 createrepo_extra_args
689 ([str]) – a list of extra arguments passed on to createrepo or
690 createrepo_c executable. This could be useful for enabling
691 zchunk generation and pointing it to correct dictionaries.
692 product_id = None
694 (scm_dict) – If specified, it should point to a directory with
695 certificates <variant_uid>-<arch>-*.pem. Pungi will copy each
696 certificate file into the relevant Yum repositories as a produc‐
697 tid file in the repodata directories. The purpose of these pro‐
698 ductid files is to expose the product data to
699 subscription-manager. subscription-manager inclues a “prod‐
700 uct-id” Yum plugin that can read these productid certificate
701 files from each Yum repository.
702 product_id_allow_missing = False
704 (bool) – When product_id is used and a certificate for some
705 variant and architecture is missing, Pungi will exit with an
706 error by default. When you set this option to True, Pungi will
707 ignore the missing certificate and simply log a warning message.
708 Example
710 createrepo_checksum = "sha"
711 createrepo_deltas = [
712 # All arches for Everything should have deltas.
713 ('^Everything$', {'*': True}),
714 # Also Server.x86_64 should have them (but not on other arches).
715 ('^Server$', {'x86_64': True}),
716 ]
717 Package Set Settings
719 Options
720 sigkeys
721 ([str or None]) – priority list of sigkeys; if the list includes
722 an empty string or None, unsigned packages will be allowed
723 pkgset_source [mandatory]
725 (str) – “koji” (any koji instance) or “repos” (arbitrary yum
726 repositories)
727 pkgset_koji_tag
729 (str|[str]) – tag(s) to read package set from. This option can
730 be omitted for modular composes.
731 pkgset_koji_builds
733 (str|[str]) – extra build(s) to include in a package set defined
734 as NVRs.
735 pkgset_koji_module_tag
737 (str|[str]) – tags to read module from. This option works simi‐
738 larly to listing tags in variants XML. If tags are specified and
739 variants XML specifies some modules via NSVC (or part of), only
740 modules matching that list will be used (and taken from the
741 tag). Inheritance is used automatically.
742 pkgset_koji_inherit = True
744 (bool) – inherit builds from parent tags; we can turn it off
745 only if we have all builds tagged in a single tag
746 pkgset_koji_inherit_modules = False
748 (bool) – the same as above, but this only applies to modular
749 tags. This option applies to the content tags that contain the
750 RPMs.
751 pkgset_repos
753 (dict) – A mapping of architectures to repositories with RPMs:
754 {arch: [repo]}. Only use when pkgset_source = "repos".
755 pkgset_exclusive_arch_considers_noarch = True
757 (bool) – If a package includes noarch in its ExclusiveArch tag,
758 it will be included in all architectures since noarch is compat‐
759 ible with everything. Set this option to False to ignore noarch
760 in ExclusiveArch and always consider only binary architectures.
761 Example
763 sigkeys = [None]
764 pkgset_source = "koji"
765 pkgset_koji_tag = "f23"
766 Buildinstall Settings
768 Script or process that creates bootable images with Anaconda installer
769 is historically called buildinstall.
770 Options
772 buildinstall_method
773 (str) – “lorax” (f16+, rhel7+) or “buildinstall” (older
774 releases)
775 lorax_options
777 (list) – special options passed on to lorax.
778 Format: [(variant_uid_regex, {arch|*: {option: name}})].
780 Recognized options are:
782 · bugurl – str (default None)
784 · nomacboot – bool (default True)
786 · noupgrade – bool (default True)
788 · add_template – [str] (default empty)
790 · add_arch_template – [str] (default empty)
792 · add_template_var – [str] (default empty)
794 · add_arch_template_var – [str] (default empty)
796 · rootfs_size – [int] (default empty)
798 · version – [str] (default from treeinfo_version or
800 release_version) – used as --version and --release
801 argument on the lorax command line
802 · dracut_args – [[str]] (default empty) override argu‐
804 ments for dracut. Please note that if this option is
805 used, lorax will not use any other arguments, so you
806 have to provide a full list and can not just add some‐
807 thing.
808 lorax_extra_sources
810 (list) – a variant/arch mapping with urls for extra source
811 repositories added to Lorax command line. Either one repo or a
812 list can be specified.
813 lorax_use_koji_plugin = False
815 (bool) – When set to True, the Koji pungi_buildinstall task will
816 be used to execute Lorax instead of runroot. Use only if the
817 Koji instance has the pungi_buildinstall plugin installed.
818 buildinstall_kickstart
820 (scm_dict) – If specified, this kickstart file will be copied
821 into each file and pointed to in boot configuration.
822 buildinstall_topdir
824 (str) – Full path to top directory where the runroot buildin‐
825 stall Koji tasks output should be stored. This is useful in sit‐
826 uation when the Pungi compose is not generated on the same stor‐
827 age as the Koji task is running on. In this case, Pungi can pro‐
828 vide input repository for runroot task using HTTP and set the
829 output directory for this task to buildinstall_topdir. Once the
830 runroot task finishes, Pungi will copy the results of runroot
831 tasks to the compose working directory.
832 buildinstall_skip
834 (list) – mapping that defines which variants and arches to skip
835 during buildinstall; format: [(variant_uid_regex, {arch|*:
836 True})]. This is only supported for lorax.
837 Example
839 buildinstall_method = "lorax"
840 # Enables macboot on x86_64 for all variants and builds upgrade images
842 # everywhere.
843 lorax_options = [
844 ("^.*$", {
845 "x86_64": {
846 "nomacboot": False
847 }
848 "*": {
849 "noupgrade": False
850 }
851 })
852 ]
853 # Don't run buildinstall phase for Modular variant
855 buildinstall_skip = [
856 ('^Modular', {
857 '*': True
858 })
859 ]
860 # Add another repository for lorax to install packages from
862 lorax_extra_sources = [
863 ('^Simple$', {
864 '*': 'https://example.com/repo/$basearch/',
865 })
866 ]
867 NOTE:
869 It is advised to run buildinstall (lorax) in koji, i.e. with runroot
870 enabled for clean build environments, better logging, etc.
871 WARNING:
873 Lorax installs RPMs into a chroot. This involves running %post
874 scriptlets and they frequently run executables in the chroot. If
875 we’re composing for multiple architectures, we must use runroot for
876 this reason.
877 Gather Settings
879 Options
880 gather_method [mandatory]
881 (str*|*dict) – Options are deps, nodeps and hybrid. Specifies
882 whether and how package dependencies should be pulled in. Pos‐
883 sible configuration can be one value for all variants, or if
884 configured per-variant it can be a simple string hybrid or a a
885 dictionary mapping source type to a value of deps or nodeps.
886 Make sure only one regex matches each variant, as there is no
887 guarantee which value will be used if there are multiple match‐
888 ing ones. All used sources must have a configured method unless
889 hybrid solving is used.
890 gather_fulltree = False
892 (bool) – When set to True all RPMs built from an SRPM will
893 always be included. Only use when gather_method = "deps".
894 gather_selfhosting = False
896 (bool) – When set to True, Pungi will build a self-hosting tree
897 by following build dependencies. Only use when gather_method =
898 "deps".
899 gather_allow_reuse = False
901 (bool) – When set to True, Pungi will try to reuse gather
902 results from old compose specified by --old-composes.
903 greedy_method
905 (str) – This option controls how package requirements are satis‐
906 fied in case a particular Requires has multiple candidates.
907 · none – the best packages is selected to satisfy the dependency
909 and only that one is pulled into the compose
910 · all – packages that provide the symbol are pulled in
912 · build – the best package is selected, and then all packages
914 from the same build that provide the symbol are pulled in
915 NOTE:
917 As an example let’s work with this situation: a package in
918 the compose has Requires: foo. There are three packages with
919 Provides: foo: pkg-a, pkg-b-provider-1 and pkg-b-provider-2.
920 The pkg-b-* packages are build from the same source package.
921 Best match determines pkg-b-provider-1 as best matching pack‐
922 age.
923 · With greedy_method = "none" only pkg-b-provider-1 will be
925 pulled in.
926 · With greedy_method = "all" all three packages will be
928 pulled in.
929 · With greedy_method = "build" ``pkg-b-provider-1 and
931 pkg-b-provider-2 will be pulled in.
932 gather_backend
934 (str) –This changes the entire codebase doing dependency solv‐
935 ing, so it can change the result in unpredictable ways.
936 On Python 2, the choice is between yum or dnf and defaults to
938 yum. On Python 3 dnf is the only option and default.
939 Particularly the multilib work is performed differently by using
941 python-multilib library. Please refer to multilib option to see
942 the differences.
943 multilib
945 (list) – mapping of variant regexes and arches to list of multi‐
946 lib methods
947 Available methods are:
949 · none – no package matches this method
951 · all – all packages match this method
953 · runtime – packages that install some shared object file
955 (*.so.*) will match.
956 · devel – packages whose name ends with -devel or
958 --static suffix will be matched. When dnf is used, this
959 method automatically enables runtime method as well.
960 With yum backend this method also uses a hardcoded
961 blacklist and whitelist.
962 · kernel – packages providing kernel or kernel-devel
964 match this method (only in yum backend)
965 · yaboot – only yaboot package on ppc arch matches this
967 (only in yum backend)
968 additional_packages
970 (list) – additional packages to be included in a variant and
971 architecture; format: [(variant_uid_regex, {arch|*: [pack‐
972 age_globs]})]
973 The packages specified here are matched against RPM names, not
975 any other provides in the package not the name of source pack‐
976 age. Shell globbing is used, so wildcards are possible. The
977 package can be specified as name only or name.arch.
978 With dnf gathering backend, you can specify a debuginfo package
980 to be included. This is meant to include a package if autodetec‐
981 tion does not get it. If you add a debuginfo package that does
982 not have anything else from the same build included in the com‐
983 pose, the sources will not be pulled in.
984 filter_packages
986 (list) – packages to be excluded from a variant and architec‐
987 ture; format: [(variant_uid_regex, {arch|*: [package_globs]})]
988 See additional_packages for details about package specification.
990 filter_modules
992 (list) – modules to be excluded from a variant and architecture;
993 format: [(variant_uid_regex, {arch|*: [name:stream]})]
994 Both name and stream can use shell-style globs. If stream is
996 omitted, all streams are removed.
997 This option only applies to modules taken from Koji tags, not
999 modules explicitly listed in variants XML without any tags.
1000 filter_system_release_packages
1002 (bool) – for each variant, figure out the best system release
1003 package and filter out all others. This will not work if a vari‐
1004 ant needs more than one system release package. In such case,
1005 set this option to False.
1006 gather_prepopulate = None
1008 (scm_dict) – If specified, you can use this to add additional
1009 packages. The format of the file pointed to by this option is a
1010 JSON mapping {variant_uid: {arch: {build: [package]}}}. Packages
1011 added through this option can not be removed by filter_packages.
1012 multilib_blacklist
1014 (dict) – multilib blacklist; format: {arch|*: [package_globs]}.
1015 See additional_packages for details about package specification.
1017 multilib_whitelist
1019 (dict) – multilib blacklist; format: {arch|*: [package_names]}.
1020 The whitelist must contain exact package names; there are no
1021 wildcards or pattern matching.
1022 gather_lookaside_repos = []
1024 (list) – lookaside repositories used for package gathering; for‐
1025 mat: [(variant_uid_regex, {arch|*: [repo_urls]})]
1026 hashed_directories = False
1028 (bool) – put packages into “hashed” directories, for example
1029 Packages/k/kernel-4.0.4-301.fc22.x86_64.rpm
1030 check_deps = True
1032 (bool) – Set to False if you don’t want the compose to abort
1033 when some package has broken dependencies.
1034 require_all_comps_packages = False
1036 (bool) – Set to True to abort compose when package mentioned in
1037 comps file can not be found in the package set. When disabled
1038 (the default), such cases are still reported as warnings in the
1039 log.
1040 gather_source_mapping
1042 (str) – JSON mapping with initial packages for the compose. The
1043 value should be a path to JSON file with following mapping:
1044 {variant: {arch: {rpm_name: [rpm_arch|None]}}}.
1045 gather_profiler = False
1047 (bool) – When set to True the gather tool will produce addi‐
1048 tional performance profiling information at the end of its logs.
1049 Only takes effect when gather_backend = "dnf".
1050 variant_as_lookaside
1052 (list) – a variant/variant mapping that tells one or more vari‐
1053 ants in compose has other variant(s) in compose as a lookaside.
1054 Only top level variants are supported (not addons/layered prod‐
1055 ucts). Format: [(variant_uid, variant_uid)]
1056 Example
1058 gather_method = "deps"
1059 greedy_method = "build"
1060 check_deps = False
1061 hashed_directories = True
1062 gather_method = {
1064 "^Everything$": {
1065 "comps": "deps" # traditional content defined by comps groups
1066 },
1067 "^Modular$": {
1068 "module": "nodeps" # Modules do not need dependencies
1069 },
1070 "^Mixed$": { # Mixed content in one variant
1071 "comps": "deps",
1072 "module": "nodeps"
1073 }
1074 "^OtherMixed$": "hybrid", # Using hybrid depsolver
1075 }
1076 additional_packages = [
1078 # bz#123456
1079 ('^(Workstation|Server)$', {
1080 '*': [
1081 'grub2',
1082 'kernel',
1083 ],
1084 }),
1085 ]
1086 filter_packages = [
1088 # bz#111222
1089 ('^.*$', {
1090 '*': [
1091 'kernel-doc',
1092 ],
1093 }),
1094 ]
1095 multilib = [
1097 ('^Server$', {
1098 'x86_64': ['devel', 'runtime']
1099 })
1100 ]
1101 multilib_blacklist = {
1103 "*": [
1104 "gcc",
1105 ],
1106 }
1107 multilib_whitelist = {
1109 "*": [
1110 "alsa-plugins-*",
1111 ],
1112 }
1113 # gather_lookaside_repos = [
1115 # ('^.*$', {
1116 # 'x86_64': [
1117 # "https://dl.fedoraproject.org/pub/fedora/linux/releases/22/Everything/x86_64/os/",
1118 # "https://dl.fedoraproject.org/pub/fedora/linux/releases/22/Everything/source/SRPMS/",
1119 # ]
1120 # }),
1121 # ]
1122 NOTE:
1124 It is a good practice to attach bug/ticket numbers to addi‐
1125 tional_packages, filter_packages, multilib_blacklist and multi‐
1126 lib_whitelist to track decisions.
1127 Koji Settings
1129 Options
1130 koji_profile
1131 (str) – koji profile name. This tells Pungi how to communicate
1132 with your chosen Koji instance. See Koji’s documentation about
1133 profiles for more information about how to set up your Koji
1134 client profile. In the examples, the profile name is “koji”,
1135 which points to Fedora’s koji.fedoraproject.org.
1136 global_runroot_method
1138 (str) – global runroot method to use. If runroot_method is set
1139 per Pungi phase using a dictionary, this option defines the
1140 default runroot method for phases not mentioned in the run‐
1141 root_method dictionary.
1142 runroot_method
1144 (str*|*dict) – Runroot method to use. It can further specify the
1145 runroot method in case the runroot is set to True.
1146 Available methods are:
1148 · local – runroot tasks are run locally
1150 · koji – runroot tasks are run in Koji
1152 · openssh – runroot tasks are run on remote machine con‐
1154 nected using OpenSSH. The runroot_ssh_hostnames for
1155 each architecture must be set and the user under which
1156 Pungi runs must be configured to login as run‐
1157 root_ssh_username using the SSH key.
1158 The runroot method can also be set per Pungi phase using the
1160 dictionary with phase name as key and runroot method as value.
1161 The default runroot method is in this case defined by the
1162 global_runroot_method option.
1163 Example
1165 global_runroot_method = "koji"
1166 runroot_method = {
1167 "createiso": "local"
1168 }
1169 runroot_channel
1171 (str) – name of koji channel
1172 runroot_tag
1174 (str) – name of koji build tag used for runroot
1175 runroot_weights
1177 (dict) – customize task weights for various runroot tasks. The
1178 values in the mapping should be integers, the keys can be
1179 selected from the following list. By default no weight is
1180 assigned and Koji picks the default one according to policy.
1181 · buildinstall
1183 · createiso
1185 · ostree
1187 · ostree_installer
1189 Example
1191 koji_profile = "koji"
1192 runroot_channel = "runroot"
1193 runroot_tag = "f23-build"
1194 Runroot “openssh” method settings
1196 Options
1197 runroot_ssh_username
1198 (str) – For openssh runroot method, configures the username used
1199 to login the remote machine to run the runroot task. Defaults to
1200 “root”.
1201 runroot_ssh_hostnames
1203 (dict) – For openssh runroot method, defines the hostname for
1204 each architecture on which the runroot task should be running.
1205 Format: {"x86_64": "runroot-x86-64.localhost.tld", ...}
1206 runroot_ssh_init_template
1208 (str) [optional] – For openssh runroot method, defines the com‐
1209 mand to initializes the runroot task on the remote machine. This
1210 command is executed as first command for each runroot task exe‐
1211 cuted.
1212 The command can print a string which is then available as {run‐
1214 root_key} for other SSH commands. This string might be used to
1215 keep the context across different SSH commands executed for sin‐
1216 gle runroot task.
1217 The goal of this command is setting up the environment for real
1219 runroot commands. For example preparing the unique mock environ‐
1220 ment, mounting the desired file-systems, …
1221 The command string can contain following variables which are
1223 replaced by the real values before executing the init command:
1224 · {runroot_tag} - Tag to initialize the runroot environment
1226 from.
1227 When not set, no init command is executed.
1229 runroot_ssh_install_packages_template
1231 (str) [optional] – For openssh runroot method, defines the tem‐
1232 plate for command to install the packages requested to run the
1233 runroot task.
1234 The template string can contain following variables which are
1236 replaced by the real values before executing the install com‐
1237 mand:
1238 · {runroot_key} - Replaced with the string returned by run‐
1240 root_ssh_init_template if used. This can be used to keep the
1241 track of context of SSH commands beloging to single runroot
1242 task.
1243 · {packages} - White-list separated list of packages to install.
1245 Example (The {runroot_key} is expected to be set to mock config
1247 file using the runroot_ssh_init_template command.): "mock -r
1248 {runroot_key} --install {packages}"
1249 When not set, no command to install packages on remote machine
1251 is executed.
1252 runroot_ssh_run_template
1254 (str) [optional] – For openssh runroot method, defines the tem‐
1255 plate for the main runroot command.
1256 The template string can contain following variables which are
1258 replaced by the real values before executing the install com‐
1259 mand:
1260 · {runroot_key} - Replaced with the string returned by run‐
1262 root_ssh_init_template if used. This can be used to keep the
1263 track of context of SSH commands beloging to single runroot
1264 task.
1265 · {command} - Command to run.
1267 Example (The {runroot_key} is expected to be set to mock config
1269 file using the runroot_ssh_init_template command.): "mock -r
1270 {runroot_key} chroot -- {command}"
1271 When not set, the runroot command is run directly.
1273 Extra Files Settings
1275 Options
1276 extra_files
1277 (list) – references to external files to be placed in os/ direc‐
1278 tory and media; format: [(variant_uid_regex, {arch|*:
1279 [scm_dict]})]. See scm_support for details. If the dict speci‐
1280 fies a target key, an additional subdirectory will be used.
1281 Example
1283 extra_files = [
1284 ('^.*$', {
1285 '*': [
1286 # GPG keys
1287 {
1288 "scm": "rpm",
1289 "repo": "fedora-repos",
1290 "branch": None,
1291 "file": [
1292 "/etc/pki/rpm-gpg/RPM-GPG-KEY-22-fedora",
1293 ],
1294 "target": "",
1295 },
1296 # GPL
1297 {
1298 "scm": "git",
1299 "repo": "https://pagure.io/pungi-fedora",
1300 "branch": None,
1301 "file": [
1302 "GPL",
1303 ],
1304 "target": "",
1305 },
1306 ],
1307 }),
1308 ]
1309 Extra Files Metadata
1311 If extra files are specified a metadata file, extra_files.json, is
1312 placed in the os/ directory and media. The checksums generated are
1313 determined by media_checksums option. This metadata file is in the for‐
1314 mat:
1315 {
1317 "header": {"version": "1.0},
1318 "data": [
1319 {
1320 "file": "GPL",
1321 "checksums": {
1322 "sha256": "8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643"
1323 },
1324 "size": 18092
1325 },
1326 {
1327 "file": "release-notes/notes.html",
1328 "checksums": {
1329 "sha256": "82b1ba8db522aadf101dca6404235fba179e559b95ea24ff39ee1e5d9a53bdcb"
1330 },
1331 "size": 1120
1332 }
1333 ]
1334 }
1335 CreateISO Settings
1337 Options
1338 createiso_skip = False
1339 (list) – mapping that defines which variants and arches to skip
1340 during createiso; format: [(variant_uid_regex, {arch|*: True})]
1341 createiso_max_size
1343 (list) – mapping that defines maximum expected size for each
1344 variant and arch. If the ISO is larger than the limit, a warning
1345 will be issued.
1346 Format: [(variant_uid_regex, {arch|*: number})]
1348 createiso_max_size_is_strict
1350 (list) – Set the value to True to turn the warning from cre‐
1351 ateiso_max_size into a hard error that will abort the compose.
1352 If there are multiple matches in the mapping, the check will be
1353 strict if at least one match says so.
1354 Format: [(variant_uid_regex, {arch|*: bool})]
1356 create_jigdo = True
1358 (bool) – controls the creation of jigdo from ISO
1359 create_optional_isos = False
1361 (bool) – when set to True, ISOs will be created even for
1362 optional variants. By default only variants with type variant or
1363 layered-product will get ISOs.
1364 createiso_break_hardlinks = False
1366 (bool) – when set to True, all files that should go on the ISO
1367 and have a hardlink will be first copied into a staging direc‐
1368 tory. This should work around a bug in genisoimage including
1369 incorrect link count in the image, but it is at the cost of hav‐
1370 ing to copy a potentially significant amount of data.
1371 The staging directory is deleted when ISO is successfully cre‐
1373 ated. In that case the same task to create the ISO will not be
1374 re-runnable.
1375 iso_size = 4700000000
1377 (int|str) – size of ISO image. The value should either be an
1378 integer meaning size in bytes, or it can be a string with k, M,
1379 G suffix (using multiples of 1024).
1380 split_iso_reserve = 10MiB
1382 (int|str) – how much free space should be left on each disk. The
1383 format is the same as for iso_size option.
1384 iso_hfs_ppc64le_compatible = True
1386 (bool) – when set to False, the Apple/HFS compatibility is
1387 turned off for ppc64le ISOs. This option only makes sense for
1388 bootable products, and affects images produced in createiso and
1389 extra_isos phases.
1390 NOTE:
1392 Source architecture needs to be listed explicitly. Excluding ‘*’
1393 applies only on binary arches. Jigdo causes significant increase of
1394 time to ISO creation.
1395 Example
1397 createiso_skip = [
1398 ('^Workstation$', {
1399 '*': True,
1400 'src': True
1401 }),
1402 ]
1403 Automatic generation of version and release
1405 Version and release values for certain artifacts can be generated auto‐
1406 matically based on release version, compose label, date, type and
1407 respin. This can be used to shorten the config and keep it the same for
1408 multiple uses.
1409┌───────────────────────┬───────────────┬──────────┬──────────┬────────┬──────────────┐
1411│Compose ID │ Label │ Version │ Date │ Respin │ Release │
1412├───────────────────────┼───────────────┼──────────┼──────────┼────────┼──────────────┤
1413│F-Rawhide-20170406.n.0 │ - │ Rawhide │ 20170406 │ 0 │ 20170406.n.0 │
1414├───────────────────────┼───────────────┼──────────┼──────────┼────────┼──────────────┤
1415│F-26-20170329.1 │ Alpha-1.6 │ 26_Alpha │ 20170329 │ 1 │ 1.6 │
1416├───────────────────────┼───────────────┼──────────┼──────────┼────────┼──────────────┤
1417│F-Atomic-25-20170407.0 │ RC-20170407.0 │ 25 │ 20170407 │ 0 │ 20170407.0 │
1418├───────────────────────┼───────────────┼──────────┼──────────┼────────┼──────────────┤
1419│F-Atomic-25-20170407.0 │ - │ 25 │ 20170407 │ 0 │ 20170407.0 │
1420└───────────────────────┴───────────────┴──────────┴──────────┴────────┴──────────────┘
1421 All non-RC milestones from label get appended to the version. For
1423 release either label is used or date, type and respin.
1424 Common options for Live Images, Live Media and Image Build
1426 All images can have ksurl, version, release and target specified. Since
1427 this can create a lot of duplication, there are global options that can
1428 be used instead.
1429 For each of the phases, if the option is not specified for a particular
1431 deliverable, an option named <PHASE_NAME>_<OPTION> is checked. If that
1432 is not specified either, the last fallback is global_<OPTION>. If even
1433 that is unset, the value is considered to not be specified.
1434 The kickstart URL is configured by these options.
1436 · global_ksurl – global fallback setting
1438 · live_media_ksurl
1440 · image_build_ksurl
1442 · live_images_ksurl
1444 Target is specified by these settings.
1446 · global_target – global fallback setting
1448 · live_media_target
1450 · image_build_target
1452 · live_images_target
1454 Version is specified by these options. If no version is set, a default
1456 value will be provided according to automatic versioning.
1457 · global_version – global fallback setting
1459 · live_media_version
1461 · image_build_version
1463 · live_images_version
1465 Release is specified by these options. If set to a magic value to
1467 !RELEASE_FROM_LABEL_DATE_TYPE_RESPIN, a value will be generated accord‐
1468 ing to automatic versioning.
1469 · global_release – global fallback setting
1471 · live_media_release
1473 · image_build_release
1475 · live_images_release
1477 Each configuration block can also optionally specify a failable key.
1479 For live images it should have a boolean value. For live media and
1480 image build it should be a list of strings containing architectures
1481 that are optional. If any deliverable fails on an optional architec‐
1482 ture, it will not abort the whole compose. If the list contains only
1483 "*", all arches will be substituted.
1484 Live Images Settings
1486 live_images
1487 (list) – Configuration for the particular image. The elements of
1488 the list should be tuples (variant_uid_regex, {arch|*: config}).
1489 The config should be a dict with these keys:
1490 · kickstart (str)
1492 · ksurl (str) [optional] – where to get the kickstart from
1494 · name (str)
1496 · version (str)
1498 · target (str)
1500 · repo (str|[str]) – repos specified by URL or variant UID
1502 · specfile (str) – for images wrapped in RPM
1504 · scratch (bool) – only RPM-wrapped images can use scratch
1506 builds, but by default this is turned off
1507 · type (str) – what kind of task to start in Koji. Defaults
1509 to live meaning koji spin-livecd will be used. Alternative
1510 option is appliance corresponding to koji spin-appliance.
1511 · sign (bool) – only RPM-wrapped images can be signed
1513 live_images_no_rename
1515 (bool) – When set to True, filenames generated by Koji will be
1516 used. When False, filenames will be generated based on
1517 image_name_format configuration option.
1518 Live Media Settings
1520 live_media
1521 (dict) – configuration for koji spin-livemedia; format: {vari‐
1522 ant_uid_regex: [{opt:value}]}
1523 Required options:
1525 · name (str)
1527 · version (str)
1529 · arches ([str]) – what architectures to build the media for;
1531 by default uses all arches for the variant.
1532 · kickstart (str) – name of the kickstart file
1534 Available options:
1536 · ksurl (str)
1538 · ksversion (str)
1540 · scratch (bool)
1542 · target (str)
1544 · release (str) – a string with the release, or
1546 !RELEASE_FROM_LABEL_DATE_TYPE_RESPIN to automatically gen‐
1547 erate a suitable value. See automatic versioning for
1548 details.
1549 · skip_tag (bool)
1551 · repo (str|[str]) – repos specified by URL or variant UID
1553 · title (str)
1555 · install_tree_from (str) – variant to take install tree from
1557 Image Build Settings
1559 image_build
1560 (dict) – config for koji image-build; format: {vari‐
1561 ant_uid_regex: [{opt: value}]}
1562 By default, images will be built for each binary arch valid for
1564 the variant. The config can specify a list of arches to narrow
1565 this down.
1566 NOTE:
1568 Config can contain anything what is accepted by koji image-build
1569 --config configfile.ini
1570 Repo can be specified either as a string or a list of strings. It
1572 will be automatically transformed into format suitable for koji. A
1573 repo for the currently built variant will be added as well.
1574 If you explicitly set release to
1576 !RELEASE_FROM_LABEL_DATE_TYPE_RESPIN, it will be replaced with a
1577 value generated as described in automatic versioning.
1578 If you explicitly set release to !RELEASE_FROM_DATE_RESPIN, it will
1580 be replaced with a value generated as described in automatic ver‐
1581 sioning.
1582 If you explicitly set version to !VERSION_FROM_VERSION, it will be
1584 replaced with a value generated as described in automatic version‐
1585 ing.
1586 Please don’t set install_tree. This gets automatically set by pungi
1588 based on current variant. You can use install_tree_from key to use
1589 install tree from another variant.
1590 Both the install tree and repos can use one of following formats:
1592 · URL to the location
1594 · name of variant in the current compose
1596 · absolute path on local filesystem (which will be translated
1598 using configured mappings or used unchanged, in which case you
1599 have to ensure the koji builders can access it)
1600 You can set either a single format, or a list of formats. For avail‐
1602 able values see help output for koji image-build command.
1603 If ksurl ends with #HEAD, Pungi will figure out the SHA1 hash of
1605 current HEAD and use that instead.
1606 Setting scratch to True will run the koji tasks as scratch builds.
1608 Example
1610 image_build = {
1611 '^Server$': [
1612 {
1613 'image-build': {
1614 'format': ['docker', 'qcow2']
1615 'name': 'fedora-qcow-and-docker-base',
1616 'target': 'koji-target-name',
1617 'ksversion': 'F23', # value from pykickstart
1618 'version': '23',
1619 # correct SHA1 hash will be put into the URL below automatically
1620 'ksurl': 'https://git.fedorahosted.org/git/spin-kickstarts.git?somedirectoryifany#HEAD',
1621 'kickstart': "fedora-docker-base.ks",
1622 'repo': ["http://someextrarepos.org/repo", "ftp://rekcod.oi/repo"],
1623 'distro': 'Fedora-20',
1624 'disk_size': 3,
1625 # this is set automatically by pungi to os_dir for given variant
1627 # 'install_tree': 'http://somepath',
1628 },
1629 'factory-parameters': {
1630 'docker_cmd': "[ '/bin/bash' ]",
1631 'docker_env': "[ 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' ]",
1632 'docker_labels': "{'Name': 'fedora-docker-base', 'License': u'GPLv2', 'RUN': 'docker run -it --rm ${OPT1} --privileged -v \`pwd\`:/atomicapp -v /run:/run -v /:/host --net=host --name ${NAME} -e NAME=${NAME} -e IMAGE=${IMAGE} ${IMAGE} -v ${OPT2} run ${OPT3} /atomicapp', 'Vendor': 'Fedora Project', 'Version': '23', 'Architecture': 'x86_64' }",
1633 }
1634 },
1635 {
1636 'image-build': {
1637 'format': ['docker', 'qcow2']
1638 'name': 'fedora-qcow-and-docker-base',
1639 'target': 'koji-target-name',
1640 'ksversion': 'F23', # value from pykickstart
1641 'version': '23',
1642 # correct SHA1 hash will be put into the URL below automatically
1643 'ksurl': 'https://git.fedorahosted.org/git/spin-kickstarts.git?somedirectoryifany#HEAD',
1644 'kickstart': "fedora-docker-base.ks",
1645 'repo': ["http://someextrarepos.org/repo", "ftp://rekcod.oi/repo"],
1646 'distro': 'Fedora-20',
1647 'disk_size': 3,
1648 # this is set automatically by pungi to os_dir for given variant
1650 # 'install_tree': 'http://somepath',
1651 }
1652 },
1653 {
1654 'image-build': {
1655 'format': 'qcow2',
1656 'name': 'fedora-qcow-base',
1657 'target': 'koji-target-name',
1658 'ksversion': 'F23', # value from pykickstart
1659 'version': '23',
1660 'ksurl': 'https://git.fedorahosted.org/git/spin-kickstarts.git?somedirectoryifany#HEAD',
1661 'kickstart': "fedora-docker-base.ks",
1662 'distro': 'Fedora-23',
1663 # only build this type of image on x86_64
1665 'arches': ['x86_64']
1666 # Use install tree and repo from Everything variant.
1668 'install_tree_from': 'Everything',
1669 'repo': ['Everything'],
1670 # Set release automatically.
1672 'release': '!RELEASE_FROM_LABEL_DATE_TYPE_RESPIN',
1673 }
1674 }
1675 ]
1676 }
1677 OSTree Settings
1679 The ostree phase of Pungi can create and update ostree repositories.
1680 This is done by running rpm-ostree compose in a Koji runroot environ‐
1681 ment. The ostree repository itself is not part of the compose and
1682 should be located in another directory. Any new packages in the compose
1683 will be added to the repository with a new commit.
1684 ostree (dict) – a mapping of configuration for each. The format should
1686 be {variant_uid_regex: config_dict}. It is possible to use a
1687 list of configuration dicts as well.
1688 The configuration dict for each variant arch pair must have
1690 these keys:
1691 · treefile – (str) Filename of configuration for rpm-ostree.
1693 · config_url – (str) URL for Git repository with the treefile.
1695 · repo – (str|dict|[str|dict]) repos specified by URL or variant
1697 UID or a dict of repo options, baseurl is required in the
1698 dict.
1699 · ostree_repo – (str) Where to put the ostree repository
1701 These keys are optional:
1703 · keep_original_sources – (bool) Keep the existing source repos
1705 in the tree config file. If not enabled, all the original
1706 source repos will be removed from the tree config file.
1707 · config_branch – (str) Git branch of the repo to use. Defaults
1709 to master.
1710 · arches – ([str]) List of architectures for which to update
1712 ostree. There will be one task per architecture. By default
1713 all architectures in the variant are used.
1714 · failable – ([str]) List of architectures for which this deliv‐
1716 erable is not release blocking.
1717 · update_summary – (bool) Update summary metadata after tree
1719 composing. Defaults to False.
1720 · force_new_commit – (bool) Do not use rpm-ostree’s built-in
1722 change detection. Defaults to False.
1723 · version – (str) Version string to be added as versioning meta‐
1725 data. If this option is set to !OSTREE_VER‐
1726 SION_FROM_LABEL_DATE_TYPE_RESPIN, a value will be generated
1727 automatically as $VERSION.$RELEASE. If this option is set to
1728 !VERSION_FROM_VERSION_DATE_RESPIN, a value will be generated
1729 automatically as $VERSION.$DATE.$RESPIN. See how those values
1730 are created.
1731 · tag_ref – (bool, default True) If set to False, a git refer‐
1733 ence will not be created.
1734 · ostree_ref – (str) To override value ref from treefile.
1736 Example config
1738 ostree = {
1739 "^Atomic$": {
1740 "treefile": "fedora-atomic-docker-host.json",
1741 "config_url": "https://git.fedorahosted.org/git/fedora-atomic.git",
1742 "repo": [
1743 "Server",
1744 "http://example.com/repo/x86_64/os",
1745 {"baseurl": "Everything"},
1746 {"baseurl": "http://example.com/linux/repo", "exclude": "systemd-container"},
1747 ],
1748 "keep_original_sources": True,
1749 "ostree_repo": "/mnt/koji/compose/atomic/Rawhide/",
1750 "update_summary": True,
1751 # Automatically generate a reasonable version
1752 "version": "!OSTREE_VERSION_FROM_LABEL_DATE_TYPE_RESPIN",
1753 # Only run this for x86_64 even if Atomic has more arches
1754 "arches": ["x86_64"],
1755 }
1756 }
1757 Ostree Installer Settings
1759 The ostree_installer phase of Pungi can produce installer image
1760 bundling an OSTree repository. This always runs in Koji as a runroot
1761 task.
1762 ostree_installer
1764 (dict) – a variant/arch mapping of configuration. The format
1765 should be [(variant_uid_regex, {arch|*: config_dict})].
1766 The configuration dict for each variant arch pair must have this
1768 key:
1769 These keys are optional:
1771 · repo – (str|[str]) repos specified by URL or variant UID
1773 · release – (str) Release value to set for the installer image.
1775 Set to !RELEASE_FROM_LABEL_DATE_TYPE_RESPIN to generate the
1776 value automatically.
1777 · failable – ([str]) List of architectures for which this deliv‐
1779 erable is not release blocking.
1780 These optional keys are passed to lorax to customize the build.
1782 · installpkgs – ([str])
1784 · add_template – ([str])
1786 · add_arch_template – ([str])
1788 · add_template_var – ([str])
1790 · add_arch_template_var – ([str])
1792 · rootfs_size – ([str])
1794 · template_repo – (str) Git repository with extra templates.
1796 · template_branch – (str) Branch to use from template_repo.
1798 The templates can either be absolute paths, in which case they
1800 will be used as configured; or they can be relative paths, in
1801 which case template_repo needs to point to a Git repository from
1802 which to take the templates.
1803 If the templates need to run with additional dependencies, that
1805 can be configured with the optional key:
1806 · extra_runroot_pkgs – ([str])
1808 ostree_installer_overwrite = False
1810 (bool) – by default if a variant including OSTree installer also
1811 creates regular installer images in buildinstall phase, there
1812 will be conflicts (as the files are put in the same place) and
1813 Pungi will report an error and fail the compose.
1814 With this option it is possible to opt-in for the overwriting.
1816 The traditional boot.iso will be in the iso/ subdirectory.
1817 Example config
1819 ostree_installer = [
1820 ("^Atomic$", {
1821 "x86_64": {
1822 "repo": [
1823 "Everything",
1824 "https://example.com/extra-repo1.repo",
1825 "https://example.com/extra-repo2.repo",
1826 ],
1827 "release": "!RELEASE_FROM_LABEL_DATE_TYPE_RESPIN",
1828 "installpkgs": ["fedora-productimg-atomic"],
1829 "add_template": ["atomic-installer/lorax-configure-repo.tmpl"],
1830 "add_template_var": [
1831 "ostree_osname=fedora-atomic",
1832 "ostree_ref=fedora-atomic/Rawhide/x86_64/docker-host",
1833 ],
1834 "add_arch_template": ["atomic-installer/lorax-embed-repo.tmpl"],
1835 "add_arch_template_var": [
1836 "ostree_repo=https://kojipkgs.fedoraproject.org/compose/atomic/Rawhide/",
1837 "ostree_osname=fedora-atomic",
1838 "ostree_ref=fedora-atomic/Rawhide/x86_64/docker-host",
1839 ]
1840 'template_repo': 'https://git.fedorahosted.org/git/spin-kickstarts.git',
1841 'template_branch': 'f24',
1842 }
1843 })
1844 ]
1845 OSBS Settings
1847 Pungi can build container images in OSBS. The build is initiated
1848 through Koji container-build plugin. The base image will be using RPMs
1849 from the current compose and a Dockerfile from specified Git reposi‐
1850 tory.
1851 Please note that the image is uploaded to a registry and not exported
1853 into compose directory. There will be a metadata file in compose/meta‐
1854 data/osbs.json with details about the built images (assuming they are
1855 not scratch builds).
1856 osbs (dict) – a mapping from variant regexes to configuration blocks.
1858 The format should be {variant_uid_regex: [config_dict]}.
1859 The configuration for each image must have at least these keys:
1861 · url – (str) URL pointing to a Git repository with Dockerfile.
1863 Please see Git URLs section for more details.
1864 · target – (str) A Koji target to build the image for.
1866 · git_branch – (str) A branch in SCM for the Dockerfile. This is
1868 required by OSBS to avoid race conditions when multiple builds
1869 from the same repo are submitted at the same time. Please note
1870 that url should contain the branch or tag name as well, so
1871 that it can be resolved to a particular commit hash.
1872 Optionally you can specify failable. If it has a truthy value,
1874 failure to create the image will not abort the whole compose.
1875 NOTE:
1877 Once OSBS gains support for multiple architectures, the usage
1878 of this option will most likely change to list architectures
1879 that are allowed to fail.
1880 The configuration will pass other attributes directly to the
1882 Koji task. This includes scratch and priority.
1883 A value for yum_repourls will be created automatically and point
1885 at a repository in the current compose. You can add extra repos‐
1886 itories with repo key having a list of urls pointing to .repo
1887 files or just variant uid, Pungi will create the .repo file for
1888 that variant. gpgkey can be specified to enable gpgcheck in repo
1889 files for variants.
1890 osbs_registries
1892 (dict) – It is possible to configure extra information about
1893 where to push the image (unless it is a scratch build). For each
1894 finished build, Pungi will try to match NVR against a key in
1895 this mapping (using shell-style globbing) and take the corre‐
1896 sponding value and collect them across all built images. The
1897 data will be saved into logs/global/osbs-registries.json as a
1898 mapping from Koji NVR to the registry data. The same data is
1899 also sent to the message bus on osbs-request-push topic once the
1900 compose finishes successfully. Handling the message and perform‐
1901 ing the actual push is outside of scope for Pungi.
1902 Example config
1904 osbs = {
1905 "^Server$": {
1906 # required
1907 "url": "git://example.com/dockerfiles.git?#HEAD",
1908 "target": "f24-docker-candidate",
1909 "git_branch": "f24-docker",
1910 # optional
1912 "repo": ["Everything", "https://example.com/extra-repo.repo"],
1913 # This will result in three repo urls being passed to the task.
1914 # They will be in this order: Server, Everything, example.com/
1915 "gpgkey": 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release',
1916 }
1917 }
1918 Extra ISOs
1920 Create an ISO image that contains packages from multiple variants. Such
1921 ISO always belongs to one variant, and will be stored in ISO directory
1922 of that variant.
1923 The ISO will be bootable if buildinstall phase runs for the parent
1925 variant. It will reuse boot configuration from that variant.
1926 extra_isos
1928 (dict) – a mapping from variant UID regex to a list of configu‐
1929 ration blocks.
1930 · include_variants – (list) list of variant UIDs from which con‐
1932 tent should be added to the ISO; the variant of this image is
1933 added automatically.
1934 Rest of configuration keys is optional.
1936 · filename – (str) template for naming the image. In addition to
1938 the regular placeholders filename is available with the name
1939 generated using image_name_format option.
1940 · volid – (str) template for generating volume ID. Again volid
1942 placeholder can be used similarly as for file name. This can
1943 also be a list of templates that will be tried sequentially
1944 until one generates a volume ID that fits into 32 character
1945 limit.
1946 · extra_files – (list) a list of scm_dict objects. These files
1948 will be put in the top level directory of the image.
1949 · arches – (list) a list of architectures for which to build
1951 this image. By default all arches from the variant will be
1952 used. This option can be used to limit them.
1953 · failable_arches – (list) a list of architectures for which the
1955 image can fail to be generated and not fail the entire com‐
1956 pose.
1957 · skip_src – (bool) allows to disable creating an image with
1959 source packages.
1960 · inherit_extra_files – (bool) by default extra files in vari‐
1962 ants are ignored. If you want to include them in the ISO, set
1963 this option to True.
1964 · max_size – (int) expected maximum size in bytes. If the final
1966 image is larger, a warning will be issued.
1967 Example config
1969 extra_isos = {
1970 'Server': [{
1971 # Will generate foo-DP-1.0-20180510.t.43-Server-x86_64-dvd1.iso
1972 'filename': 'foo-{filename}',
1973 'volid': 'foo-{arch}',
1974 'extra_files': [{
1976 'scm': 'git',
1977 'repo': 'https://pagure.io/pungi.git',
1978 'file': 'setup.py'
1979 }],
1980 'include_variants': ['Client']
1982 }]
1983 }
1984 # This should create image with the following layout:
1985 # .
1986 # ├── Client
1987 # │ ├── Packages
1988 # │ │ ├── a
1989 # │ │ └── b
1990 # │ └── repodata
1991 # ├── Server
1992 # │ ├── Packages
1993 # │ │ ├── a
1994 # │ │ └── b
1995 # │ └── repodata
1996 # └── setup.py
1997 Media Checksums Settings
1999 media_checksums
2000 (list) – list of checksum types to compute, allowed values are
2001 anything supported by Python’s hashlib module (see documentation
2002 for details).
2003 media_checksum_one_file
2005 (bool) – when True, only one CHECKSUM file will be created per
2006 directory; this option requires media_checksums to only specify
2007 one type
2008 media_checksum_base_filename
2010 (str) – when not set, all checksums will be save to a file named
2011 either CHECKSUM or based on the digest type; this option allows
2012 adding any prefix to that name
2013 It is possible to use format strings that will be replace by
2015 actual values. The allowed keys are:
2016 · arch
2018 · compose_id
2020 · date
2022 · label
2024 · label_major_version
2026 · release_short
2028 · respin
2030 · type
2032 · type_suffix
2034 · version
2036 · dirname (only if media_checksum_one_file is enabled)
2038 For example, for Fedora the prefix should be
2040 %(release_short)s-%(variant)s-%(version)s-%(date)s%(type_suf‐
2041 fix)s.%(respin)s.
2042 Translate Paths Settings
2044 translate_paths
2045 (list) – list of paths to translate; format: [(path, trans‐
2046 lated_path)]
2047 NOTE:
2049 This feature becomes useful when you need to transform compose loca‐
2050 tion into e.g. a HTTP repo which is can be passed to koji
2051 image-build. The path part is normalized via os.path.normpath().
2052 Example config
2054 translate_paths = [
2055 ("/mnt/a", "http://b/dir"),
2056 ]
2057 Example usage
2059 >>> from pungi.util import translate_paths
2060 >>> print translate_paths(compose_object_with_mapping, "/mnt/a/c/somefile")
2061 http://b/dir/c/somefile
2062 Miscellaneous Settings
2064 paths_module
2065 (str) – Name of Python module implementing the same interface as
2066 pungi.paths. This module can be used to override where things
2067 are placed.
2068 link_type = hardlink-or-copy
2070 (str) – Method of putting packages into compose directory.
2071 Available options:
2073 · hardlink-or-copy
2075 · hardlink
2077 · copy
2079 · symlink
2081 · abspath-symlink
2083 skip_phases
2085 (list) – List of phase names that should be skipped. The same
2086 functionality is available via a command line option.
2087 release_discinfo_description
2089 (str) – Override description in .discinfo files. The value is a
2090 format string accepting %(variant_name)s and %(arch)s placehold‐
2091 ers.
2092 symlink_isos_to
2094 (str) – If set, the ISO files from buildinstall, createiso and
2095 live_images phases will be put into this destination, and a sym‐
2096 link pointing to this location will be created in actual compose
2097 directory.
2098 dogpile_cache_backend
2100 (str) – If set, Pungi will use the configured Dogpile cache
2101 backend to cache various data between multiple Pungi calls. This
2102 can make Pungi faster in case more similar composes are running
2103 regularly in short time.
2104 For list of available backends, please see the
2106 https://dogpilecache.readthedocs.io documentation.
2107 Most typical configuration uses the dogpile.cache.dbm backend.
2109 dogpile_cache_arguments
2111 (dict) – Arguments to be used when creating the Dogpile cache
2112 backend. See the particular backend’s configuration for the
2113 list of possible key/value pairs.
2114 For the dogpile.cache.dbm backend, the value can be for example
2116 following:
2117 {
2119 "filename": "/tmp/pungi_cache_file.dbm"
2120 }
2121 dogpile_cache_expiration_time
2123 (int) – Defines the default expiration time in seconds of data
2124 stored in the Dogpile cache. Defaults to 3600 seconds.
2125
2127 Actual Pungi configuration files can get very large. This pages brings
2128 two examples of (almost) full configuation for two different composes.
2129 Fedora Rawhide compose
2131 This is a shortened configuration for Fedora Radhide compose as of
2132 2019-10-14.
2133 release_name = 'Fedora'
2135 release_short = 'Fedora'
2136 release_version = 'Rawhide'
2137 release_is_layered = False
2138 bootable = True
2140 comps_file = {
2141 'scm': 'git',
2142 'repo': 'https://pagure.io/fedora-comps.git',
2143 'branch': 'master',
2144 'file': 'comps-rawhide.xml',
2145 # Merge translations by running make. This command will generate the file.
2146 'command': 'make comps-rawhide.xml'
2147 }
2148 module_defaults_dir = {
2149 'scm': 'git',
2150 'repo': 'https://pagure.io/releng/fedora-module-defaults.git',
2151 'branch': 'master',
2152 'dir': '.'
2153 }
2154 variants_file='variants-fedora.xml'
2156 sigkeys = ['12C944D0']
2157 # Put packages into subdirectories hashed by their initial letter.
2159 hashed_directories = True
2160 # There is a special profile for use with compose. It makes Pungi
2162 # authenticate automatically as rel-eng user.
2163 koji_profile = 'compose_koji'
2164 # RUNROOT settings
2166 runroot = True
2167 runroot_channel = 'compose'
2168 runroot_tag = 'f32-build'
2169 # PKGSET
2171 pkgset_source = 'koji'
2172 pkgset_koji_tag = 'f32'
2173 pkgset_koji_inherit = False
2174 filter_system_release_packages = False
2176 # GATHER
2178 gather_method = {
2179 '^.*': { # For all variants
2180 'comps': 'deps', # resolve dependencies for packages from comps file
2181 'module': 'nodeps', # but not for packages from modules
2182 }
2183 }
2184 gather_backend = 'dnf'
2185 gather_profiler = True
2186 check_deps = False
2187 greedy_method = 'build'
2188 repoclosure_backend = 'dnf'
2190 # CREATEREPO
2192 createrepo_deltas = False
2193 createrepo_database = True
2194 createrepo_use_xz = True
2195 createrepo_extra_args = ['--zck', '--zck-dict-dir=/usr/share/fedora-repo-zdicts/rawhide']
2196 # CHECKSUMS
2198 media_checksums = ['sha256']
2199 media_checksum_one_file = True
2200 media_checksum_base_filename = '%(release_short)s-%(variant)s-%(version)s-%(arch)s-%(date)s%(type_suffix)s.%(respin)s'
2201 # CREATEISO
2203 iso_hfs_ppc64le_compatible = False
2204 create_jigdo = False
2205 # BUILDINSTALL
2207 buildinstall_method = 'lorax'
2208 buildinstall_skip = [
2209 # No installer for Modular variant
2210 ('^Modular$', {'*': True}),
2211 # No 32 bit installer for Everything.
2212 ('^Everything$', {'i386': True}),
2213 ]
2214 # Enables macboot on x86_64 for all variants and disables upgrade image building
2216 # everywhere.
2217 lorax_options = [
2218 ('^.*$', {
2219 'x86_64': {
2220 'nomacboot': False
2221 },
2222 'ppc64le': {
2223 # Use 3GB image size for ppc64le.
2224 'rootfs_size': 3
2225 },
2226 '*': {
2227 'noupgrade': True
2228 }
2229 })
2230 ]
2231 additional_packages = [
2233 ('^(Server|Everything)$', {
2234 '*': [
2235 # Add all architectures of dracut package.
2236 'dracut.*',
2237 # All all packages matching this pattern
2238 'autocorr-*',
2239 ],
2240 }),
2241 ('^Everything$', {
2243 # Everything should include all packages from the tag. This only
2244 # applies to the native arch. Multilib will still be pulled in
2245 # according to multilib rules.
2246 '*': ['*'],
2247 }),
2248 ]
2249 filter_packages = [
2251 ("^.*$", {"*": ["glibc32", "libgcc32"]}),
2252 ('(Server)$', {
2253 '*': [
2254 'kernel*debug*',
2255 'kernel-kdump*',
2256 ]
2257 }),
2258 ]
2259 multilib = [
2261 ('^Everything$', {
2262 'x86_64': ['devel', 'runtime'],
2263 })
2264 ]
2265 # These packages should never be multilib on any arch.
2267 multilib_blacklist = {
2268 '*': [
2269 'kernel', 'kernel-PAE*', 'kernel*debug*', 'java-*', 'php*', 'mod_*', 'ghc-*'
2270 ],
2271 }
2272 # These should be multilib even if they don't match the rules defined above.
2274 multilib_whitelist = {
2275 '*': ['wine', '*-static'],
2276 }
2277 createiso_skip = [
2279 # Keep binary ISOs for Server, but not source ones.
2280 ('^Server$', {'src': True}),
2281 # Remove all other ISOs.
2283 ('^Everything$', {'*': True, 'src': True}),
2284 ('^Modular$', {'*': True, 'src': True}),
2285 ]
2286 # Image name respecting Fedora's image naming policy
2288 image_name_format = '%(release_short)s-%(variant)s-%(disc_type)s-%(arch)s-%(version)s-%(date)s%(type_suffix)s.%(respin)s.iso'
2289 # Use the same format for volume id
2290 image_volid_formats = [
2291 '%(release_short)s-%(variant)s-%(disc_type)s-%(arch)s-%(version)s'
2292 ]
2293 # Used by Pungi to replace 'Cloud' with 'C' (etc.) in ISO volume IDs.
2294 # There is a hard 32-character limit on ISO volume IDs, so we use
2295 # these to try and produce short enough but legible IDs. Note this is
2296 # duplicated in Koji for live images, as livemedia-creator does not
2297 # allow Pungi to tell it what volume ID to use. Note:
2298 # https://fedoraproject.org/wiki/User:Adamwill/Draft_fedora_image_naming_policy
2299 volume_id_substitutions = {
2300 'Beta': 'B',
2301 'Rawhide': 'rawh',
2302 'Silverblue': 'SB',
2303 'Cinnamon': 'Cinn',
2304 'Cloud': 'C',
2305 'Design_suite': 'Dsgn',
2306 'Electronic_Lab': 'Elec',
2307 'Everything': 'E',
2308 'Scientific_KDE': 'SciK',
2309 'Security': 'Sec',
2310 'Server': 'S',
2311 'Workstation': 'WS',
2312 }
2313 disc_types = {
2315 'boot': 'netinst',
2316 'live': 'Live',
2317 }
2318 translate_paths = [
2320 ('/mnt/koji/compose/', 'https://kojipkgs.fedoraproject.org/compose/'),
2321 ]
2322 # These will be inherited by live_media, live_images and image_build
2324 global_ksurl = 'git+https://pagure.io/fedora-kickstarts.git?#HEAD'
2325 global_release = '!RELEASE_FROM_LABEL_DATE_TYPE_RESPIN'
2326 global_version = 'Rawhide'
2327 # live_images ignores this in favor of live_target
2328 global_target = 'f32'
2329 image_build = {
2331 '^Container$': [
2332 {
2333 'image-build': {
2334 'format': [('docker', 'tar.xz')],
2335 'name': 'Fedora-Container-Base',
2336 'kickstart': 'fedora-container-base.ks',
2337 'distro': 'Fedora-22',
2338 'disk_size': 5,
2339 'arches': ['armhfp', 'aarch64', 'ppc64le', 's390x', 'x86_64'],
2340 'repo': 'Everything',
2341 'install_tree_from': 'Everything',
2342 'subvariant': 'Container_Base',
2343 'failable': ['*'],
2344 },
2345 'factory-parameters': {
2346 'dockerversion': "1.10.1",
2347 'docker_cmd': '[ "/bin/bash" ]',
2348 'docker_env': '[ "DISTTAG=f32container", "FGC=f32", "container=oci" ]',
2349 'docker_label': '{ "name": "fedora", "license": "MIT", "vendor": "Fedora Project", "version": "32"}',
2350 },
2351 },
2352 ],
2353 }
2354 live_media = {
2356 '^Workstation$': [
2357 {
2358 'name': 'Fedora-Workstation-Live',
2359 'kickstart': 'fedora-live-workstation.ks',
2360 # Variants.xml also contains aarch64 and armhfp, but there
2361 # should be no live media for those arches.
2362 'arches': ['x86_64', 'ppc64le'],
2363 'failable': ['ppc64le'],
2364 # Take packages and install tree from Everything repo.
2365 'repo': 'Everything',
2366 'install_tree_from': 'Everything',
2367 }
2368 ],
2369 '^Spins': [
2370 # There are multiple media for Spins variant. They use subvariant
2371 # field so that they can be indentified in the metadata.
2372 {
2373 'name': 'Fedora-KDE-Live',
2374 'kickstart': 'fedora-live-kde.ks',
2375 'arches': ['x86_64'],
2376 'repo': 'Everything',
2377 'install_tree_from': 'Everything',
2378 'subvariant': 'KDE'
2379 },
2381 {
2382 'name': 'Fedora-Xfce-Live',
2383 'kickstart': 'fedora-live-xfce.ks',
2384 'arches': ['x86_64'],
2385 'failable': ['*'],
2386 'repo': 'Everything',
2387 'install_tree_from': 'Everything',
2388 'subvariant': 'Xfce'
2389 },
2390 ],
2391 }
2392 failable_deliverables = [
2394 # Installer and ISOs for server failing do not abort the compose.
2395 ('^Server$', {
2396 '*': ['buildinstall', 'iso'],
2397 }),
2398 ('^.*$', {
2399 # Buildinstall is not blocking
2400 'src': ['buildinstall'],
2401 # Nothing on i386, ppc64le blocks the compose
2402 'i386': ['buildinstall', 'iso'],
2403 'ppc64le': ['buildinstall', 'iso'],
2404 's390x': ['buildinstall', 'iso'],
2405 })
2406 ]
2407 live_target = 'f32'
2409 live_images_no_rename = True
2410 live_images = [
2411 ('^Workstation$', {
2412 'armhfp': {
2413 'kickstart': 'fedora-arm-workstation.ks',
2414 'name': 'Fedora-Workstation-armhfp',
2415 # Again workstation takes packages from Everything.
2416 'repo': 'Everything',
2417 'type': 'appliance',
2418 'failable': True,
2419 }
2420 }),
2421 ('^Server$', {
2422 # But Server has its own repo.
2423 'armhfp': {
2424 'kickstart': 'fedora-arm-server.ks',
2425 'name': 'Fedora-Server-armhfp',
2426 'type': 'appliance',
2427 'failable': True,
2428 }
2429 }),
2430 ]
2431 ostree = {
2433 "^Silverblue$": {
2434 "version": "!OSTREE_VERSION_FROM_LABEL_DATE_TYPE_RESPIN",
2435 # To get config, clone master branch from this repo and take
2436 # treefile from there.
2437 "treefile": "fedora-silverblue.yaml",
2438 "config_url": "https://pagure.io/workstation-ostree-config.git",
2439 "config_branch": "master",
2440 # Consume packages from Everything
2441 "repo": "Everything",
2442 # Don't create a reference in the ostree repo (signing automation does that).
2443 "tag_ref": False,
2444 # Don't use change detection in ostree.
2445 "force_new_commit": True,
2446 # This is the location for the repo where new commit will be
2447 # created. Note that this is outside of the compose dir.
2448 "ostree_repo": "/mnt/koji/compose/ostree/repo/",
2449 "ostree_ref": "fedora/rawhide/${basearch}/silverblue",
2450 "arches": ["x86_64", "ppc64le", "aarch64"],
2451 "failable": ['*'],
2452 }
2453 }
2454 ostree_installer = [
2456 ("^Silverblue$", {
2457 "x86_64": {
2458 "repo": "Everything",
2459 "release": None,
2460 "rootfs_size": "8",
2461 # Take templates from this repository.
2462 'template_repo': 'https://pagure.io/fedora-lorax-templates.git',
2463 'template_branch': 'master',
2464 # Use following templates.
2465 "add_template": ["ostree-based-installer/lorax-configure-repo.tmpl",
2466 "ostree-based-installer/lorax-embed-repo.tmpl",
2467 "ostree-based-installer/lorax-embed-flatpaks.tmpl"],
2468 # And add these variables for the templates.
2469 "add_template_var": [
2470 "ostree_install_repo=https://kojipkgs.fedoraproject.org/compose/ostree/repo/",
2471 "ostree_update_repo=https://ostree.fedoraproject.org",
2472 "ostree_osname=fedora",
2473 "ostree_oskey=fedora-32-primary",
2474 "ostree_contenturl=mirrorlist=https://ostree.fedoraproject.org/mirrorlist",
2475 "ostree_install_ref=fedora/rawhide/x86_64/silverblue",
2476 "ostree_update_ref=fedora/rawhide/x86_64/silverblue",
2477 "flatpak_remote_name=fedora",
2478 "flatpak_remote_url=oci+https://registry.fedoraproject.org",
2479 "flatpak_remote_refs=runtime/org.fedoraproject.Platform/x86_64/f30 app/org.gnome.Baobab/x86_64/stable",
2480 ],
2481 'failable': ['*'],
2482 },
2483 })
2484 ]
2485 RCM Tools compose
2487 This is a small compose used to deliver packages to Red Hat internal
2488 users. The configuration is split into two files.
2489 # rcmtools-common.conf
2491 release_name = "RCM Tools"
2493 release_short = "RCMTOOLS"
2494 release_version = "2.0"
2495 release_type = "updates"
2496 release_is_layered = True
2497 createrepo_c = True
2498 createrepo_checksum = "sha256"
2499 # PKGSET
2501 pkgset_source = "koji"
2502 koji_profile = "brew"
2503 pkgset_koji_inherit = True
2504 # GENERAL SETTINGS
2507 bootable = False
2508 comps_file = "rcmtools-comps.xml"
2509 variants_file = "rcmtools-variants.xml"
2510 sigkeys = ["3A3A33A3"]
2511 # RUNROOT settings
2514 runroot = False
2515 # GATHER
2518 gather_method = "deps"
2519 check_deps = True
2520 additional_packages = [
2522 ('.*', {
2523 '*': ['puddle', 'rcm-nexus'],
2524 }
2525 ),
2526 ]
2527 # Set repoclosure_strictness to fatal to avoid installation dependency
2529 # issues in production composes
2530 repoclosure_strictness = [
2531 ("^.*$", {
2532 "*": "fatal"
2533 })
2534 ]
2535 Configuration specific for different base products is split into sepa‐
2537 rate files.
2538 # rcmtools-common.conf
2540 from rcmtools-common import *
2541 # BASE PRODUCT
2543 base_product_name = "Red Hat Enterprise Linux"
2544 base_product_short = "RHEL"
2545 base_product_version = "7"
2546 # PKGSET
2548 pkgset_koji_tag = "rcmtools-rhel-7-compose"
2549 # remove i386 arch on rhel7
2551 tree_arches = ["aarch64", "ppc64le", "s390x", "x86_64"]
2552 check_deps = False
2554 # Packages in these repos are available to satisfy dependencies inside the
2556 # compose, but will not be pulled in.
2557 gather_lookaside_repos = [
2558 ("^Client|Client-optional$", {
2559 "x86_64": [
2560 "http://example.redhat.com/rhel/7/Client/x86_64/os/",
2561 "http://example.redhat.com/rhel/7/Client/x86_64/optional/os/",
2562 ],
2563 }),
2564 ("^Workstation|Workstation-optional$", {
2565 "x86_64": [
2566 "http://example.redhat.com/rhel/7/Workstation/x86_64/os/",
2567 "http://example.redhat.com/rhel/7/Workstation/x86_64/optional/os/",
2568 ],
2569 }),
2570 ("^Server|Server-optional$", {
2571 "aarch64": [
2572 "http://example.redhat.com/rhel/7/Server/aarch64/os/",
2573 "http://example.redhat.com/rhel/7/Server/aarch64/optional/os/",
2574 ],
2575 "ppc64": [
2576 "http://example.redhat.com/rhel/7/Server/ppc64/os/",
2577 "http://example.redhat.com/rhel/7/Server/ppc64/optional/os/",
2578 ],
2579 "ppc64le": [
2580 "http://example.redhat.com/rhel/7/Server/ppc64le/os/",
2581 "http://example.redhat.com/rhel/7/Server/ppc64le/optional/os/",
2582 ],
2583 "s390x": [
2584 "http://example.redhat.com/rhel/7/Server/s390x/os/",
2585 "http://example.redhat.com/rhel/7/Server/s390x/optional/os/",
2586 ],
2587 "x86_64": [
2588 "http://example.redhat.com/rhel/7/Server/x86_64/os/",
2589 "http://example.redhat.com/rhel/7/Server/x86_64/optional/os/",
2590 ],
2591 })
2592 ]
2593
2595 Multiple places in Pungi can use files from external storage. The con‐
2596 figuration is similar independently of the backend that is used,
2597 although some features may be different.
2598 The so-called scm_dict is always put into configuration as a dictio‐
2600 nary, which can contain following keys.
2601 · scm – indicates which SCM system is used. This is always required.
2603 Allowed values are:
2604 · file – copies files from local filesystem
2606 · git – copies files from a Git repository
2608 · cvs – copies files from a CVS repository
2610 · rpm – copies files from a package in the compose
2612 · koji – downloads archives from a given build in Koji build system
2614 · repo
2616 · for Git and CVS backends this should be URL to the repository
2618 · for RPM backend this should be a shell style glob matching package
2620 names (or a list of such globs)
2621 · for file backend this should be empty
2623 · for Koji backend this should be an NVR or package name
2625 · branch
2627 · branch name for Git and CVS backends, with master and HEAD as
2629 defaults
2630 · Koji tag for koji backend if only package name is given
2632 · otherwise should not be specified
2634 · file – a list of files that should be exported.
2636 · dir – a directory that should be exported. All its contents will be
2638 exported. This option is mutually exclusive with file.
2639 · command – defines a shell command to run after Git clone to generate
2641 the needed file (for example to run make). Only supported in Git
2642 backend.
2643 Koji examples
2645 There are two different ways how to configure the Koji backend.
2646 {
2648 # Download all *.tar files from build my-image-1.0-1.
2649 "scm": "koji",
2650 "repo": "my-image-1.0-1",
2651 "file": "*.tar",
2652 }
2653 {
2655 # Find latest build of my-image in tag my-tag and take files from
2656 # there.
2657 "scm": "koji",
2658 "repo": "my-image",
2659 "branch": "my-tag",
2660 "file": "*.tar",
2661 }
2662 Using both tag name and exact NVR will result in error: the NVR would
2664 be interpreted as a package name, and would not match anything.
2665 file vs. dir
2667 Exactly one of these two options has to be specified. Documentation for
2668 each configuration option should specify whether it expects a file or a
2669 directory.
2670 For extra_files phase either key is valid and should be chosen depend‐
2672 ing on what the actual use case.
2673 Caveats
2675 The rpm backend can only be used in phases that would extract the files
2676 after pkgset phase finished. You can’t get comps file from a package.
2677 Depending on Git repository URL configuration Pungi can only export the
2679 requested content using git archive. When a command should run this is
2680 not possible and a clone is always needed.
2681 When using koji backend, it is required to provide configuration for
2683 Koji profile to be used (koji_profile). It is not possible to contact
2684 multiple different Koji instances.
2685
2687 Pungi has the ability to emit notification messages about progress and
2688 general status of the compose. These can be used to e.g. send messages
2689 to fedmsg. This is implemented by actually calling a separate script.
2690 The script will be called with one argument describing action that just
2692 happened. A JSON-encoded object will be passed to standard input to
2693 provide more information about the event. At the very least, the object
2694 will contain a compose_id key.
2695 The script is invoked in compose directory and can read other informa‐
2697 tion there.
2698 Currently these messages are sent:
2700 · status-change – when composing starts, finishes or fails; a status
2702 key is provided to indicate details
2703 · phase-start – on start of a phase
2705 · phase-stop – when phase is finished
2707 · createiso-targets – with a list of images to be created
2709 · createiso-imagedone – when any single image is finished
2711 · createiso-imagefail – when any single image fails to create
2713 · fail-to-start – when there are incorrect CLI options or errors in
2715 configuration file; this message does not contain compose_id nor
2716 is it started in the compose directory (which does not exist yet)
2717 · ostree – when a new commit is created, this message will announce
2719 its hash and the name of ref it is meant for.
2720 For phase related messages phase_name key is provided as well.
2722 A pungi-fedmsg-notification script is provided and understands this
2724 interface.
2725 Setting it up
2727 The script should be provided as a command line argument --notifica‐
2728 tion-script.
2729 --notification-script=pungi-fedmsg-notification
2731
2733 A compose created by Pungi consists of one or more variants. A variant
2734 contains a subset of the content targeted at a particular use case.
2735 There are different types of variants. The type affects how packages
2737 are gathered into the variant.
2738 The inputs for gathering are defined by various gather sources. Pack‐
2740 ages from all sources are collected to create a big list of package
2741 names, comps groups names and a list of packages that should be fil‐
2742 tered out.
2743 NOTE:
2745 The inputs for both explicit package list and comps file are inter‐
2746 preted as RPM names, not any arbitrary provides nor source package
2747 name.
2748 Next, gather_method defines how the list is processed. For nodeps, the
2750 results from source are used pretty much as is [1]. For deps method, a
2751 process will be launched to figure out what dependencies are needed and
2752 those will be pulled in.
2753 [1] The lists are filtered based on what packages are available in the
2755 package set, but nothing else will be pulled in.
2756 Variant types
2758 Variant
2759 is a base type that has no special behaviour.
2760 Addon is built on top of a regular variant. Any packages that should
2762 go to both the addon and its parent will be removed from addon.
2763 Packages that are only in addon but pulled in because of
2764 gather_fulltree option will be moved to parent.
2765 Integrated Layered Product
2767 works similarly to addon. Additionally, all packages from addons
2768 on the same parent variant are removed integrated layered prod‐
2769 ucts.
2770 The main difference between an addon and integrated layered
2772 product is that integrated layered product has its own identity
2773 in the metadata (defined with product name and version).
2774 NOTE:
2776 There’s also Layered Product as a term, but this is not
2777 related to variants. It’s used to describe a product that is
2778 not a standalone operating system and is instead meant to be
2779 used on some other base system.
2780 Optional
2782 contains packages that complete the base variants’ package set.
2783 It always has fulltree and selfhosting enabled, so it contains
2784 build dependencies and packages which were not specifically
2785 requested for base variant.
2786 Some configuration options are overridden for particular variant types.
2788 Depsolving configuration
2790 ┌──────────┬──────────────┬──────────────┐
2791 │Variant │ Fulltree │ Selfhosting │
2792 ├──────────┼──────────────┼──────────────┤
2793 │base │ configurable │ configurable │
2794 ├──────────┼──────────────┼──────────────┤
2795 │addon/ILP │ enabled │ disabled │
2796 ├──────────┼──────────────┼──────────────┤
2797 │optional │ enabled │ enabled │
2798 └──────────┴──────────────┴──────────────┘
2799 Profiling
2801 Profiling data on the pungi-gather tool can be enabled by setting the
2802 gather_profiler configuration option to True.
2803 Modular compose
2805 A compose with gather_source set to module is called modular. The pack‐
2806 age list is determined by a list of modules.
2807 The list of modules that will be put into a variant is defined in the
2809 variants.xml file. The file can contain either Name:Stream or
2810 Name:Stream:Version references. See Module Naming Policy for details.
2811 When Version is missing from the specification, Pungi will ask PDC for
2812 the latest one.
2813 The module metadata in PDC contains a list of RPMs in the module as
2815 well as Koji tag from which the packages can be retrieved.
2816 Restrictions
2818 · A modular compose must always use Koji as a package set source.
2819
2821 The comps file that Pungi takes as input is not really pure comps as
2822 used by tools like DNF. There are extensions used to customize how the
2823 file is processed.
2824 The first step of Pungi processing is to retrieve the actual file. This
2826 can use anything that scm_support supports.
2827 Pungi extensions are arch attribute on packageref, group and environ‐
2829 ment tags. The value of this attribute is a comma separated list of
2830 architectures.
2831 Second step Pungi performs is creating a file for each architecture.
2833 This is done by removing all elements with incompatible arch attribute.
2834 No additional clean up is performed on this file. The resulting file is
2835 only used internally for the rest of the compose process.
2836 Third and final step is to create comps file for each Variant.Arch com‐
2838 bination. This is the actual file that will be included in the com‐
2839 pose. The start file is the original input file, from which all ele‐
2840 ments with incompatible architecture are removed. Then clean up is per‐
2841 formed by removing all empty groups, removing non-existing groups from
2842 environments and categories and finally removing empty environments and
2843 categories. As a last step groups not listed in the variants file are
2844 removed.
2845
2847 Set up development environment
2848 In order to work on Pungi, you should install recent version of Fedora.
2849 These packages will have to installed:
2850 · createrepo_c
2852 · cvs
2854 · gcc
2856 · genisoimage
2858 · gettext
2860 · git
2862 · gobject-introspection
2864 · isomd5sum
2866 · jigdo
2868 · kobo
2870 · krb5-devel
2872 · libcurl-devel
2874 · libmodulemd
2876 · libselinux-python
2878 · lorax
2880 · python-dogpile-cache
2882 · python-jsonschema
2884 · python-kickstart
2886 · python-libcomps
2888 · python-lockfile
2890 · python-lxml
2892 · python2-multilib
2894 · python-productmd
2896 · PyYAML
2898 · repoview
2900 · rpm-devel
2902 · syslinux
2904 · yum
2906 · yum-utils
2908 For running unit tests, these packages are recommended as well:
2910 · python-mock
2912 · python-nose
2914 · python-nose-cov
2916 · python-unittest2
2918 · rpmdevtools
2920 · python-parameterized
2922 While being difficult, it is possible to work on Pungi using vir‐
2924 tualenv. Install python-virtualenvwrapper (after installation you have
2925 to add the command to source /usr/local/bin/virtualenvwrapper.sh to
2926 your shell startup file, depending on where it was installed by package
2927 manager) and use following steps. It will link system libraries into
2928 the virtual environment and install all packages preferably from PyPI
2929 or from tarball. You will still need to install all of the non-Python
2930 packages above as they are used by calling an executable.
2931 $ mkvirtualenv pungienv
2933 $ for pkg in gi libcomps pykickstart rpmUtils selinux urlgrabber yum; do ln -vs "$(deactivate && python -c 'import os, '$pkg'; print(os.path.dirname('$pkg'.__file__))')" "$(virtualenvwrapper_get_site_packages_dir)"; done
2934 $ for pkg in _deltarpm krbV _selinux deltarpm sqlitecachec _sqlitecache; do ln -vs "$(deactivate && python -c 'import os, '$pkg'; print('$pkg'.__file__)')" "$(virtualenvwrapper_get_site_packages_dir)"; done
2935 $ pip install -U pip
2936 $ PYCURL_SSL_LIBRARY=nss pip install pycurl --no-binary :all:
2937 $ pip install beanbag jsonschema 'kobo>=0.6.0' lockfile lxml mock nose nose-cov productmd pyopenssl python-multilib requests requests-kerberos setuptools sphinx ordered_set koji PyYAML dogpile.cache parameterized
2938 Now you should be able to run all existing tests.
2940 Developing
2942 Currently the development workflow for Pungi is on master branch:
2943 · Make your own fork at https://pagure.io/pungi
2945 · Clone your fork locally (replacing $USERNAME with your own):
2947 git clone git@pagure.io:forks/$USERNAME/pungi.git
2949 · cd into your local clone and add the remote upstream for rebasing:
2951 cd pungi
2953 git remote add upstream git@pagure.io:pungi.git
2954 NOTE:
2956 This workflow assumes that you never git commit directly to the
2957 master branch of your fork. This will make more sense when we
2958 cover rebasing below.
2959 · create a topic branch based on master:
2961 git branch my_topic_branch master
2963 git checkout my_topic_branch
2964 · Make edits, changes, add new features, etc. and then make sure to
2966 pull from upstream master and rebase before submitting a pull
2967 request:
2968 # lets just say you edited setup.py for sake of argument
2970 git checkout my_topic_branch
2971 # make changes to setup.py
2973 black setup.py
2974 tox
2975 git add setup.py
2976 git commit -s -m "added awesome feature to setup.py"
2977 # now we rebase
2979 git checkout master
2980 git pull --rebase upstream master
2981 git push origin master
2982 git push origin --tags
2983 git checkout my_topic_branch
2984 git rebase master
2985 # resolve merge conflicts if any as a result of your development in
2987 # your topic branch
2988 git push origin my_topic_branch
2989 NOTE:
2991 In order to for your commit to be merged:
2992 · you must sign-off on it. Use -s option when running git commit.
2994 · The code must be well formatted via black and pass flake8 check‐
2996 ing. Run tox to do the check.
2997 · Create pull request in the pagure.io web UI
2999 · For convenience, here is a bash shell function that can be placed in
3001 your ~/.bashrc and called such as pullupstream pungi-4-devel that
3002 will automate a large portion of the rebase steps from above:
3003 pullupstream () {
3005 if [[ -z "$1" ]]; then
3006 printf "Error: must specify a branch name (e.g. - master, devel)\n"
3007 else
3008 pullup_startbranch=$(git describe --contains --all HEAD)
3009 git checkout $1
3010 git pull --rebase upstream master
3011 git push origin $1
3012 git push origin --tags
3013 git checkout ${pullup_startbranch}
3014 fi
3015 }
3016 Testing
3018 You must write unit tests for any new code (except for trivial
3019 changes). Any code without sufficient test coverage may not be merged.
3020 To run all existing tests, suggested method is to use nosetests. With
3022 additional options, it can generate code coverage. To make sure even
3023 tests from executable files are run, don’t forget to use the --exe
3024 option.
3025 $ make test
3027 $ make test-cover
3028 # Running single test file
3030 $ python tests/test_arch.py [TestCase...]
3031 In the tests/ directory there is a shell script test_compose.sh that
3033 you can use to try and create a miniature compose on dummy data. The
3034 actual data will be created by running make test-data in project root.
3035 $ python setup.py develop
3037 $ make test-data
3038 $ make test-compose
3039 This testing compose does not actually use all phases that are avail‐
3041 able, and there is no checking that the result is correct. It only
3042 tells you whether it crashed or not.
3043 NOTE:
3045 Even when it finishes successfully, it may print errors about
3046 repoclosure on Server-Gluster.x86_64 in test phase. This is not a
3047 bug.
3048 Documenting
3050 You must write documentation for any new features and functional
3051 changes. Any code without sufficient documentation may not be merged.
3052 To generate the documentation, run make doc in project root.
3054
3056 Test Data
3057 Tests require test data and not all of it is available in git. You
3058 must create test repositories before running the tests:
3059 make test-data
3061 Requirements: createrepo_c, rpmbuild
3063 Unit Tests
3065 Unit tests cover functionality of Pungi python modules. You can run
3066 all of them at once:
3067 make test
3069 which is shortcut to:
3071 python2 setup.py test
3073 python3 setup.py test
3074 You can alternatively run individual tests:
3076 cd tests
3078 ./<test>.py [<class>[.<test>]]
3079 Functional Tests
3081 Because compose is quite complex process and not everything is covered
3082 with unit tests yet, the easiest way how to test if your changes did
3083 not break anything badly is to start a compose on a relatively small
3084 and well defined package set:
3085 cd tests
3087 ./test_compose.sh
3088
3090 There may be cases where it makes sense to split a big compose into
3091 separate parts, but create a compose output that links all output into
3092 one familiar structure.
3093 The pungi-orchestrate tools allows that.
3095 It works with an INI-style configuration file. The [general] section
3097 contains information about identity of the main compose. Other sections
3098 define individual parts.
3099 The parts are scheduled to run in parallel, with the minimal amount of
3101 serialization. The final compose directory will contain hard-links to
3102 the files.
3103 General settings
3105 target Path to directory where the final compose should be created.
3106 compose_type
3108 Type of compose to make.
3109 release_name
3111 Name of the product for the final compose.
3112 release_short
3114 Short name of the product for the final compose.
3115 release_version
3117 Version of the product for the final compose.
3118 release_type
3120 Type of the product for the final compose.
3121 extra_args
3123 Additional arguments that wil be passed to the child Pungi pro‐
3124 cesses.
3125 koji_profile
3127 If specified, a current event will be retrieved from the Koji
3128 instance and used for all parts.
3129 kerberos
3131 If set to yes, a kerberos ticket will be automatically created
3132 at the start. Set keytab and principal as well.
3133 kerberos_keytab
3135 Path to keytab file used to create the kerberos ticket.
3136 kerberos_principal
3138 Kerberos principal for the ticket
3139 pre_compose_script
3141 Commands to execute before first part is started. Can contain
3142 multiple commands on separate lines.
3143 post_compose_script
3145 Commands to execute after the last part finishes and final sta‐
3146 tus is updated. Can contain multiple commands on separate lines.
3147 post_compose_script =
3149 compose-latest-symlink $COMPOSE_PATH
3150 custom-post-compose-script.sh
3151 Multiple environment variables are defined for the scripts:
3153 · COMPOSE_PATH
3155 · COMPOSE_ID
3157 · COMPOSE_DATE
3159 · COMPOSE_TYPE
3161 · COMPOSE_RESPIN
3163 · COMPOSE_LABEL
3165 · RELEASE_ID
3167 · RELEASE_NAME
3169 · RELEASE_SHORT
3171 · RELEASE_VERSION
3173 · RELEASE_TYPE
3175 · RELEASE_IS_LAYERED – YES for layered products, empty other‐
3177 wise
3178 · BASE_PRODUCT_NAME – only set for layered products
3180 · BASE_PRODUCT_SHORT – only set for layered products
3182 · BASE_PRODUCT_VERSION – only set for layered products
3184 · BASE_PRODUCT_TYPE – only set for layered products
3186 notification_script
3188 Executable name (or path to a script) that will be used to send
3189 a message once the compose is finished. In order for a valid URL
3190 to be included in the message, at least one part must configure
3191 path translation that would apply to location of main compose.
3192 Only two messages will be sent, one for start and one for finish
3194 (either successful or not).
3195 Partial compose settings
3197 Each part should have a separate section in the config file.
3198 It can specify these options:
3200 config Path to configuration file that describes this part. If rela‐
3202 tive, it is resolved relative to the file with parts configura‐
3203 tion.
3204 just_phase, skip_phase
3206 Customize which phases should run for this part.
3207 depends_on
3209 A comma separated list of other parts that must be finished
3210 before this part starts.
3211 failable
3213 A boolean toggle to mark a part as failable. A failure in such
3214 part will mark the final compose as incomplete, but still suc‐
3215 cessful.
3216
3218 Daniel Mach
3219
3221 2020, Red Hat, Inc.
32224.2 Mar 16, 2020 PUNGI(1)