build_id=$(copr build ... --quiet --nowait)

The command should obviously return a build ID. But how should it behave when I run just

copr build ... --quiet

without --nowait? Should it just take the prompt until the build is finished and print nothing?

Should it just take the prompt until the build is finished and print nothing?

It would seem fine if you printed the build id, and wait.. so user can handle non-zero
exit status. But please don't feel blocked to change the proposal; the point is to get
a feature to make the "batch" scripting easy - not that you have to keep the proposed
--quiet --nowait options.

Thinking aloud, and having a look at #220 again. Also this would be nice:

$ copr build ... --log-update[=5]
build is running, waiting 5s ...
build is running, waiting 5s ...
...
build succeeded

But I don't want to make the --quiet forgotten, because getting the build_id is certainly useful, e.g. to mechanically generate the "build status image url", and post it somewhere.

$ copr build ... --log-update[=5]
build is running, waiting 5s ...
build is running, waiting 5s ...
...
build succeeded

I was thinking we could have the whole builder-live.log stream to the command-line with some option e.g. --live-log.

That would be awesome, but it would be (basically) duplicate to #88, with additional issues like "multiple builder-live.log files per build" (for each chroot).

Btw. note that builder-live.log can hang for several minutes too - so travis could fail the same way even though less likely.

set -e
build_id=$(copr build ... --quiet --nowait)
while ! copr build-status --ended "$build_id"; do
echo "keep travis alive"
sleep 30
done
copr build-status --succeeded "$build_id" # Fail if something went wrong

Note that we already have:

 copr status [-h] build_id.

which returns build state number. So we just need to describe in manual what individual state numbers mean. We could also use the enums in python-copr-common and offer stringified status being returned.

So I don't think something like copr build-status --succeeded is necessary. But we could offer
copr status <build_id> --finished that would return 0/1 if the build has finished yet. Here it is advantageous because there are multiple states that correspond to a finished state. This is something that could potentially also live in python python-copr-common, e.g. something likedef build_is_finished. We already have something like that in models.py in copr-frontend.

Btw. note that builder-live.log can hang for several minutes too - so travis could fail the same way even though less likely.

Yes, well, we could fix that by starting to print dots after some time if this was a problem.

The --quiet option should print to standard output only build id (if the build has been submitted, meaning that exit status is 0). That way, we can do:

I am not sure I like --quiet very much there. I would prefer something more explicit like:

--print-build-id

If I was looking for some option that prints only build id to stdout so that I can parse it I wouldn't probably expect it under --quiet.

That would be awesome, but it would be (basically) duplicate to #88, with additional issues like "multiple builder-live.log files per build" (for each chroot).

Right, that's true. That means that copr build --live-log should have a "chroot limiting" argument or better we should offer that as a separate command that accepts a single chroot as an argument. Printing output from all the chroots at once would be...a lot of output.

Agreed. That said, live logs in commandline are long-term task, so for this particular RFE, I owuld stick with the --print-build-id option, which would probably imply --nowait naturally.

In case of renaming --quiet to more explicit argument, like --print-build-id ... I would prefer just --print-id. It is shorter and still pretty explicit, because what other ID it could be other build ID.

In case of renaming --quiet to more explicit argument, like --print-build-id ... I would prefer just --print-id. It is shorter and still pretty explicit, because what other ID it could be other build ID.

Well, e.g. build chroot ids as a list of string, but that could be --print-chroot-ids if anyone wanted it. so I am ok with just --print-id.

--print-id seems to be fine to me, too

Another problem is that when building from URL it is possible to create multiple builds at once

copr-cli build myproject https://foo/bar.src.rpm https://foo/baz.src.rpm --nowait

in such case, the naming --print-id is inaccurate, because we need to print multiple IDs. Which format do you find better, IDs separated by space or multiple lines with one ID per line?

Or, we can not-complicate things and allow --print-id only when no more than one build is submitted at once. I actually prefer this solution, because I would bet, that no one will even notice it and even if so, the workaround is straightforward. Also, we will not have to describe possible output formats of such simple feature in the documentation.

Beeing OP here, I don't mind. Limiting the --print-id to single-build requests seems fine.

Similar request reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1696468

I would recommend printing build id to a file:

copr build --print-id=build-id.txt USER/PROJECT SRPM

In such a case copr can continue printing any additional info to stdout, and shell script can handle build:

build_id=$(< build-id.txt )
copr download-build $build_id

BTW, there is no reason to limit number of ids printed. Print all build ids, one id per line. All the build ids can be easily handled by shell script:

copr build --print-id=build-ids.txt USER/PROJECT SRPM0 SRPM1...
build_ids=( $(< build-ids.txt) )
for id in ${build_ids[@]}; do
    copr download-build $id
done

Alternatively, if shell arrays are not feasible:

while read id; do
    copr download-build $id
done < build-ids.txt

This issue has been migrated to GitHub: https://github.com/fedora-copr/copr/issues/224