Hello Petr,
On Thu, Aug 24, 2017 at 1:35 PM, Petr Stodulka <pstodulk(a)redhat.com> 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>>
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
--
Petr Stodulka
Core Services (In-place upgrades and migrations)
IRC nicks: pstodulk, skytak
Red Hat
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org