koji

Execute a koji subcommand

$ koji [subcommand]

$ koji moshimoshi

$ koji [[-h|--help]]

$ koji help

$ koji [subcommand] [[-h|--help]]

$ koji version

koji [GLOBAL_OPTIONS] COMMAND [COMMAND_OPTIONS] [ARGUMENTS]

Examples:
koji --help
koji build --target=f38-build git://example.com/rpms/foo#master
koji list-builds --package=httpd

--help, -h
    Display a help message for the koji command or a specific subcommand.

--version
    Show the program's version number and exit.

--config=file
    Specify an alternate configuration file to use instead of the default (~/.koji/config).

--profile=name
    Select a specific profile from the configuration file. Useful for switching between different Koji instances or user accounts.

--server=URL
    Override the Koji XMLRPC server URL specified in the configuration file.

--weburl=URL
    Override the Koji web interface URL specified in the configuration file.

--force
    Proceed with operations that might otherwise require confirmation or be blocked by checks.

--debug
    Enable debug output, providing more detailed information about command execution.

--quiet, -q
    Suppress informational output, showing only errors or requested data.

The koji command is the primary client-side interface for interacting with the Koji build system. Koji is a powerful, distributed, and auditable build system used by projects like Fedora and Red Hat Enterprise Linux to build RPM packages.
It provides functionalities to submit new builds, monitor their progress, list existing builds, manage tags, query build information, and interact with the Koji hub and builders. It facilitates creating consistent and reproducible build environments, often integrating with tools like mock for isolated builds.

Requires a properly configured Koji client, typically located at ~/.koji/config, with valid authentication credentials.
Network connectivity to the Koji hub server is essential for all operations.
User permissions on the Koji hub dictate which operations can be performed. Insufficient permissions will result in errors.
The command has many subcommands, each with its own set of options, which can make initial usage complex.

The koji client relies on configuration files, typically ~/.koji/config and potentially other files in /etc/koji.conf.d/. These files define connection details to the Koji hub, user authentication information (e.g., certificates), and default profiles. Different profiles can be used to connect to different Koji instances or with different user identities.

Koji consists of several components:
Hub: The central server that manages builds, tags, users, and provides the XMLRPC API.
Builders: Machines that perform the actual RPM package builds in isolated mock environments.
Web Interface: A web-based front-end for viewing build status, logs, and other Koji data.
Client: The koji command-line tool used to interact with the Hub.

The koji command operates through a variety of subcommands, each performing a specific task (e.g., build, list-builds, tag-build). Each subcommand has its own set of unique options and arguments. For example, the build subcommand accepts options like --target, --scratch, and --nowait. To view options for a specific subcommand, use koji COMMAND --help (e.g., koji build --help).

The Koji build system was developed by Red Hat and the Fedora Project to serve as the official build system for the Fedora Linux distribution. It was introduced to address the growing needs for a robust, scalable, and transparent system for building RPM packages for a large-scale operating system. It became the primary build system for Fedora around 2006, replacing older, less automated methods. Its design emphasizes isolated builds using mock and comprehensive tracking of build metadata.

mock(1), rpm(8), createrepo_c(8), dnf(8)