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
On Monday, November 12, 2018 10:19:44 AM CET Jiri Kastner wrote:
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@lists.fedorahosted.org
-
Jiri Kastner -
Pavel Raiskup