Re: CI projects in Copr

[Michal Novotny <clime@xxxxxxxxxx>]

Hello Petr,

On Thu, Aug 24, 2017 at 1:35 PM, Petr Stodulka <pstodulk@xxxxxxxxxx> wrote:

On 24.8.2017 08:04, Pavel Raiskup wrote:
> On Wednesday, August 23, 2017 1:46:46 PM CEST Miroslav Suchý wrote:
>> Do you use Copr for building packages for nightlies? For building packages
>> before pull request is merged?
>
> Yes, not particulary me -- but I helped to guys in pgjdbc project to setup CI:
>
> https://copr.fedorainfracloud.org/coprs/g/pgjdbc/pgjdbc-travis/
> https://github.com/pgjdbc/pgjdbc/blob/master/packaging/rpm/fedora-image/copr-ci-git
>
>> Do you have your set up described somewhere?
>
> No, since it is too complicated.  Tito is a burden for distro-agnostic upstream.
>
> Since upstream had travis-ci already enabled, my plan was to generate src.rpm in
> travis-ci and submit build into copr (together with other CI tasks).
>
> Two major problems:
> 1. Travis is (or was that time) debian/ubuntu only, so it is actually not very
>    convenient to install all the necessary tooling there;  so the work-around
>    was to use Fedora docker-image and that image is pulled in for each CI run.
>
> 2. You need to store your copr credentials into git.  You can cipher that, but
>    at least it is not convenient to store *your own* copr authentication token
>    into git repo, because always at least other git committers can decipher it.
>    You also need to re-generate your API token twice a year (it means you need
>    to bother the upstream with "useless" commits, but the worst thing is that
>    you need to regularly go back and pay attention to fixing the CI).
>
> Being able to specify (a) scm repo, (b) build deps and (c) any (turing complete)
> script within the git repo (to generate the sources) would make setting up the
> CI a trivial task.

+1

That is something that could help us definitely too. Nowadays we have scripts for
packaging in Jenkins, that run tests and prepare SRPM for the COPR, that requires
in addition changes in upstream repository itself (e.g. public spec file as part
of the repository). More convenient would be (not only for our team, but for me too
as packager)

a) option to provide script in COPR, that will prepare sources, patches,
modified SPEC file, ... on the COPR side. The script would be processed for example
when I sent request to COPR for specific repository, with whatever data that will
be processed by the script (e.g. commit hash, branch, PR number).

b) store the specfile into the COPR repository, so it could be used by the script
   and it will not be required to be part of the upstream repository (usually the
   SPEC is not part of the upstream repo or we want different spec than upstream
   provides)

I found now that in COPR is something that b) describes, but I am not sure that
it is same. Still, own script that would prepare sources for COPR builds is the
most missing feature for me.

We are considering the options here and so far the most convenient method (at least

from the implementation point of view) seems to be to automatically call `make srpm`

command in the source git repo if user selects `make srpm` as a srpm generator

method for his (or her) SCM project (this will be a select field in UI and also it will be
a build parameter available in our future API). That means it would be a custom script
placed inside a Makefile under srpm goal. Custom packages needed for this operation could be

specified in minimal buildroot of the given chroot (in chroot settings). We will probably

also add a field to differentiate between srpm buildroot packages and rpm buildroot packages

and also make this setting available across all project chroots.

Would this cover and satisfy your needs? I would personally really like if we made it

possible for you to use COPR solely. COPR will soon become _very_ powerful tool.

>
> Pavel
>
>> What is the name of your
>> project?
>>
>> Please let me know. Either here or via private reply.
>> It will help me to understand your use of Copr and to make Copr better.
>>
>> Thanks in advance.
>>
>> Miroslav Suchy
>> _______________________________________________
>> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
>>
>
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
>

--
Petr Stodulka
Core Services (In-place upgrades and migrations)
IRC nicks: pstodulk, skytak
Red Hat


_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@lists.fedoraproject.org

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx