#517 Enhance copr-rpmbuild with `--task-file` and `--task-url` parameters
Closed: Fixed 2 years ago by frostyx. Opened 5 years ago by frostyx.

Recently I wanted to use copr-rpmbuild to locally reproduce a failing build (which is the commonly agreed purpose of this tool) and I was surprised that the most obvious task input methods are not yet implemented. The combination of build ID and chroot

copr-rpmbuild --build-id 123 --chroot fedora-rawhide-x86_64

is the most user-friendly way, that we can offer. However, it is not always the most dev-friendly option for several reasons.

  1. Multiple instances - You find that a build on dev instance fails and you want to tell someone, how to reproduce it. You need to explain the person, that he needs a copr-rpmbuild config for dev, which IMHO isn't showed anywhere - there is only a jinja2 template in ansible repo ... It is possible to do this, but it isn't ideal.
  2. Many times I work with a task on https://<frontend>/backend/get-build-task/<build_id>-<chroot> and I would like to just take the URL and pass it to the copr-rpmbuild. Instead, I need to parse the build ID and chroot from it and pass it to the copr-rpmbuild together with the correct config file. It is unnecessary workarounding of a simple thing.
  3. Sometimes as a developer, I want to reproduce a particular build locally, but change something in the task definition. There are basically two use cases. Either you want to change some value e.g. add a repository, or you work on the copr-rpmbuild itself and want to e.g. change the structure.

All of these use-cases can be covered with simple --task-file and --task-url parameters.

copr-rpmbuild --task-file /tmp/mytask.json
copr-rpmbuild --task-url https://<frontend>/backend/get-build-task/<build_id>-<chroot>

The implementation shouldn't mess with the copr-rpmbuild pipeline. In the case of --task-url, it would just request the given URL instead of constructing one from build ID and chroot. Then continue as usual. In case of --task-file, there will be a bit more deviation and instead of requesting an URL and reading json from it, it will read a file instead, and then continue as usual. Both cases should be trivial to implement.


The PR#794 is merged for a long time and I am happily using the feature.

Metadata Update from @frostyx:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata