review changes from gerrit, copr dir and modules

[Jiri Kastner]

hi all,
as user and small contributor of one project, which is using gerrit for
change review, i would like to made that reviewing as simple as possible.

today i realized that there is 'copr dir' which is used for building pull
requests, git review process using gerrit is similar but change is tracked
and versioned as long as commit contains same change-id.

i first heard about copr/dnf modules and as it allows various streams
for some package, so i was thinking about stream for change (0.10-3720,
0.10-4323,...).
within stream, change versions are tracked (in git each has own branch),
version can turn to number in %{release}.

lot of users are using debian/ubuntu so probably best option would be some
container which will allow using usb hw.

so question is what should be better approach - use dnf/copr modularity or
copr dir for such goal?

best regards
jiri kastner

[Pavel Raiskup]

Post by Jiri Kastner
as user and small contributor of one project, which is using gerrit for
change review, i would like to made that reviewing as simple as possible.
today i realized that there is 'copr dir' which is used for building pull
requests, git review process using gerrit is similar but change is tracked
and versioned as long as commit contains same change-id.
i first heard about copr/dnf modules and as it allows various streams
for some package, so i was thinking about stream for change (0.10-3720,
0.10-4323,...).
within stream, change versions are tracked (in git each has own branch),
version can turn to number in %{release}.
lot of users are using debian/ubuntu so probably best option would be some
container which will allow using usb hw.
so question is what should be better approach - use dnf/copr modularity or
copr dir for such goal?

It would be better to discuss your use-case face to face or at least on
IRC. But neither of those tools are IMO perfect fit for what you require
ATM (copr_dir is an incomplete internal for Pagure PRs, modularity
probably won't scale enough yet).

If I understand you correctly, you plan to execute `/bin/copr-cli`
commands from your CI to build your package against Fedora in Copr, to
make it easily available for `dnf install`. For that, I'd use

$ copr build your_PR_project ....

And people then can just do:

$ dnf copr enable jkastner/your_PR_project
$ dnf install your-package-NVR

Builds are garbage collected, but AFAIK only those which are older than 14
days. If that matters to you, and you really want to have only one
version of each RPM in one repository (I don't think it is anyhow more
convenient for the reviewer) feel free to use:

$ copr create your-package-PR_ID --chroot ...
$ copr build your-package-PR_ID

The major issue is that (at least at this point in time) you have to store
your copr token into gerrit, or use external CI with storage for secrets
(jenkins?) as long as you really plan to use /bin/copr.

Pavel



_______________________________________________
copr-devel mailing list -- copr-***@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-***@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/copr-***@lists.fedorahosted.or