BKR-JOB-SUBMIT(1)

📦
version 29.2 · 3 versions
, in epel 9

💖 NAME 💖

okay bestie, welcome to BKR-JOB-SUBMIT(1) — the manual page for bkr-job-submit, aka the little command that submits job XML to Beaker. That’s literally the whole vibe. ✨

🦋 SYNOPSIS 🦋

bkr job-submit [options]
  [--debug] [--convert] [--combine] [--ignore-missing-tasks]
  [--dry-run | --wait]
  [<filename>...]

🌸 DESCRIPTION 🌸

So here’s the tea: this command reads Beaker job XML descriptions and submits them straight to Beaker. 💅

You give it one or more filenames containing the job XML you want submitted. If you hand it multiple filenames, each one gets submitted as a separate job — no bundling unless you specifically ask for that later, iykyk. If you give it no filenames at all, it reads the job XML from stdin. And yes, the special filename '-' also reads from stdin, because sometimes that’s just the move. 🫶

✨ OPTIONS ✨

  • --debug — this one is a legacy option, replaced by --xml. It’s giving old-school, but we keep it around.
  • --xml — prints the job XML before submitting it. Perfect if you want to see the goods before they leave the group chat.
  • --convert — attempts to convert legacy RHTS XML to Beaker XML. Use this with --xml and --dry-run if you wanna grab the converted XML without actually submitting it. 👑
  • --combine — if more than one job XML argument is given, the recipe sets from each job are extracted and combined into a single job before submission. One job to rule them all, lowkey.
  • --ignore-missing-tasks — if the job refers to tasks that are not known to the scheduler, this silently discards those from the recipe. Normally that whole situation is a fatal error that prevents submission of the job, so yeah, this flag is the “please don’t panic” button. 😭
  • --dry-run — do not submit the job(s) to Beaker. Use this with --xml to see what would be submitted. Very “look but don’t touch” of it.
  • --wait — watches the newly submitted jobs for state changes and prints them to stdout. The command will not exit until all submitted jobs have finished. See bkr-job-watch(1). It’s giving main character energy: it stays until the jobs are done. ⭐
  • --job-owner <username> — submit the job on behalf of <username>. The submitted job will be owned by <username> rather than the submitting user.

The existing user attribute in the job XML will be overridden if set. No cap.

The submitting user must be a submission delegate of <username>. Users can add other users as submission delegates on their Preferences page in Beaker’s web UI. That’s the official bestie delegation system. 💖

Common bkr options are described in the Options section of bkr(1). Go check that out if you need the wider lore.

The synopsis puts --dry-run and --wait in an either/or slot, so don’t be weird about it.

🎀 EXIT STATUS 🎀

1 if any jobs failed submission or execution, otherwise zero. Simple, clean, iconic.

🌈 EXAMPLES 🌈

Submit a job and watch its progress on stdout:

bkr job-submit --wait my-beaker-job.xml

💜 SEE ALSO 💜

bkr(1) — the main manual page, obviously. 🫶

🧚 AUTHOR 🧚

The Beaker team <beaker-devel@lists.fedorahosted.org>

2013-2025 Red Hat, Inc.

and that’s the whole page, bestie — this BKR-JOB-SUBMIT(1) manual is from Beaker 29.2, dated May 26, 2025. periodt. 💅✨

📦 where this page comes from