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