koji-resubmit

Resubmit a task

$ koji resubmit [task_id]

$ koji resubmit [task_id] --nowait

$ koji resubmit [task_id] --quiet

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

koji resubmit [OPTIONS] [...]

--help
    Display a help message for the command and exit.

--web
    Open the submitted task in the Koji web browser interface after submission.

--nowait
    Do not wait for the resubmitted tasks to complete. The command will return immediately after submission.

--wait
    Wait for the resubmitted tasks to complete. This is useful for scripting and automation.

--priority=
    Set the priority of the resubmitted tasks. Lower numerical values indicate higher priority.

--rebuild
    Explicitly submit the task as a rebuild, inheriting details from the original successful build.

--scratch
    Submit the task as a scratch build. Scratch builds are temporary and not permanently stored in the Koji repository.

--arches=
    Limit the resubmitted build to specific target architectures, provided as a comma-separated list.

--tags=
    Resubmit the build using specific Koji build tags, provided as a comma-separated list.


    One or more numeric IDs of the Koji builds or tasks that are to be resubmitted. Multiple IDs can be provided space-separated.

The koji resubmit command is a vital client utility for the Koji build system, designed to efficiently re-submit one or more previously initiated Koji builds or tasks for processing. This command is invaluable in scenarios where a build encountered transient failures (e.g., network interruptions, temporary server overloads, or dependency unavailability) or was prematurely canceled. By simply providing the original build ID or task ID, koji resubmit re-queues the build request, typically preserving the original parameters. However, it also offers flexibility, allowing users to modify aspects like build priority, target architectures, or whether to submit it as a scratch build for testing or a formal rebuild. Its primary purpose is to streamline the recovery process for problematic builds, eliminating the need for tedious manual reconstruction of the original build command.

Permissions: Users must possess the necessary Koji permissions to resubmit builds. Unauthorized attempts will fail.
State of Build: Typically, only builds that have failed, been canceled, or are in a transient state are suitable for resubmission. Builds that have already completed successfully cannot be resubmitted.
Original Parameters: While koji resubmit aims to reuse original build parameters, certain environmental or Koji system changes might affect the outcome, and some parameters might need explicit overriding.
Resource Availability: Resubmission still depends on the Koji system's capacity, including available builders, build roots, and other required resources. The build might still fail if resources are insufficient.
Network Connectivity: A stable and active network connection to the Koji hub server is essential for the command to successfully communicate and submit tasks.

koji resubmit is a frequently utilized tool by build maintainers and release engineers. It's commonly employed to retry builds that have failed due to temporary infrastructure issues, resource contention on builders, or minor configuration errors that have subsequently been rectified. It serves as a critical mechanism for maintaining a healthy, progressing, and responsive build pipeline within large-scale software projects.

The --scratch option is used to submit a temporary build for testing purposes; these builds are not permanently stored in the Koji repository. In contrast, the --rebuild option submits a standard build that, if successful, will be stored in the Koji repository. A 'rebuild' typically attempts to reconstruct the original package from source using existing build parameters, whereas a new 'build' command might involve entirely new sources or specifications.

The koji build system, developed by the Fedora Project, was designed as a robust and scalable platform for building RPM packages. The koji resubmit command emerged as a crucial component of the koji client suite early in its development. Its genesis was driven by the practical demands of managing large-scale build environments, such as those used by Fedora. The ability to efficiently recover from transient build failures and effectively manage build queues was paramount, leading to the creation of a tool that could streamline the build process and minimize manual intervention. Over time, koji resubmit has evolved alongside the broader Koji project, with new options and functionalities incorporated to address the evolving operational requirements of build engineers and release managers.

koji(1), koji build(1), koji cancel(1), koji watch-task(1), koji list-builds(1)