Re: CI projects in Copr

We have finished the SCM source type implementation. You can read more in this blog post: https://clime.github.io/2017/10/24/COPR-SCM.html Thank you for the feedback! clime On Wed, Sep 27, 2017 at 10:28 PM, Michal Novotny wrote: > Hello, > > On Tue, Sep 5, 2017 at 5:50 PM,

Re: CI projects in Copr

Hello, On Tue, Sep 5, 2017 at 5:50 PM, Petr Stodulka wrote: > > > On 4.9.2017 19:27, Michal Novotny wrote: > > I might contact you for more information, but alright, if you feel the > custom script is more convenient, > > then I am all for it. But first, I would like to

Re: CI projects in Copr

On Fri, Sep 1, 2017 at 11:20 AM, Gerd Hoffmann wrote: > Hi, > > > It's easier on implementation. That's the main reason. I generally > > believe that > > what's easier on implementation is better. > > It's maybe easier on the copr side, but not for the copr users ... > > If

Re: CI projects in Copr

On 4.9.2017 19:27, Michal Novotny wrote: > I might contact you for more information, but alright, if you feel the custom > script is more convenient, > then I am all for it. But first, I would like to make a proposal of each > option (with screenshots and > just complete feature request

Re: CI projects in Copr

Hey, Petr On Mon, Sep 4, 2017 at 4:27 PM, Petr Stodulka wrote: > I apologize for late response as I was on holiday. Not sure if you already > talked together about that but I agree with Pavel. `make srpm` solves only > _one_ > type of troubles. I guess that usually I will

Re: CI projects in Copr

I apologize for late response as I was on holiday. Not sure if you already talked together about that but I agree with Pavel. `make srpm` solves only _one_ type of troubles. I guess that usually I will get response from upstream like that: -- we will not add Makefile just because of COPR that is

Re: CI projects in Copr

On Friday, September 1, 2017 12:16:32 PM CEST Michal Novotny wrote: > On Fri, Sep 1, 2017 at 8:55 AM, Marc Dequènes (Duck) > > On 09/01/2017 01:28 AM, Michal Novotny wrote: > > > But I think an off-line talk might be the best. Depends on you. > > > > I can understand you don't

Re: CI projects in Copr

On Fri, Sep 1, 2017 at 1:41 PM, Gerd Hoffmann wrote: > Hi, > > > Right, this is cool. The problem is that the upstream repo would need > > to be configured to provide a public message that something has been > > changed > > in it (i.e. new release) so the question is how to

Re: CI projects in Copr

Hi, > Right, this is cool. The problem is that the upstream repo would need > to be configured to provide a public message that something has been > changed > in it (i.e. new release) so the question is how to do this part. Ah, right, setting up a webhook needs access to the upstream repo too.

Re: CI projects in Copr

Hey Marc, On Fri, Sep 1, 2017 at 8:55 AM, Marc Dequènes (Duck) wrote: > Quack, > > On 09/01/2017 01:28 AM, Michal Novotny wrote: > > > But I think an off-line talk might be the best. Depends on you. > > I can understand you don't want this thread to end-up in flames, and yes >

Re: CI projects in Copr

2017-09-01 11:20 GMT+02:00 Gerd Hoffmann : > So, what would be really helpful, especially for CI with the option to > build and test every upstream commit, would be support for *two* git > repos. One git repo where the spec-file and other build-related stuff > lives (distgit

Re: CI projects in Copr

Hello Gerd, On Fri, Sep 1, 2017 at 11:20 AM, Gerd Hoffmann wrote: > Hi, > > > It's easier on implementation. That's the main reason. I generally > > believe that > > what's easier on implementation is better. > > It's maybe easier on the copr side, but not for the copr

Re: CI projects in Copr

Hi, > It's easier on implementation. That's the main reason. I generally > believe that  > what's easier on implementation is better. It's maybe easier on the copr side, but not for the copr users ... If you can modify the upstream project (either because you are upstream, or in case upstream

Re: CI projects in Copr

Quack, On 09/01/2017 01:28 AM, Michal Novotny wrote: > But I think an off-line talk might be the best. Depends on you. I can understand you don't want this thread to end-up in flames, and yes sometimes it helps to have a live direct talk, but this also means the rest of this list is kept out. I

Re: CI projects in Copr

Hello Pavel, On Thu, Aug 31, 2017 at 4:37 PM, Pavel Raiskup wrote: > On Thursday, August 31, 2017 3:48:21 PM CEST Michal Novotny wrote: > > a) you need an additional db field. you need to have more inputs in SCM > tabs > > when one has a meaning only if 'custom' is

Re: CI projects in Copr

On Thursday, August 31, 2017 3:48:21 PM CEST Michal Novotny wrote: > a) you need an additional db field. you need to have more inputs in SCM tabs > when one has a meaning only if 'custom' is selected in the srpm_generator > select (which means you should hide/unhide that by js in frontend to have

Re: CI projects in Copr

On Thu, Aug 31, 2017 at 1:47 PM, Pavel Raiskup wrote: > On Thursday, August 31, 2017 11:43:08 AM CEST Michal Novotny wrote: > > On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup > wrote: > > > I'm curious why you insist on 'make srpm'; that sounds like

Re: CI projects in Copr

On Thursday, August 31, 2017 11:43:08 AM CEST Michal Novotny wrote: > On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup wrote: > > I'm curious why you insist on 'make srpm'; that sounds like you try to push > > the copr users somewhere, to "standardize something". > > It's

Re: CI projects in Copr

On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup wrote: > On Wednesday, August 30, 2017 5:18:39 PM CEST Michal Novotny wrote: > > 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 >

Re: CI projects in Copr

Hello, I'm using Jenkins for pOCCI testsuite tool [1] (COPR repository is [2]). I'm building everything in Jenkins using my own scripts for several OS (Fedora/EPEL, Debian), but I've added also COPR as optional step in the build workflow. Source rpms are generated locally by Jenkins and then is

Re: CI projects in Copr

On Thursday, August 31, 2017 8:43:38 AM CEST Pavel Raiskup wrote: > On Wednesday, August 30, 2017 5:18:39 PM CEST Michal Novotny wrote: > > 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

Re: CI projects in Copr

On Wednesday, August 30, 2017 5:18:39 PM CEST Michal Novotny wrote: > 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

Re: CI projects in Copr

Hello Martin, On Wed, Aug 23, 2017 at 2:02 PM, Martin Sehnoutka wrote: > Hi, > > I'm using Copr for build on commit for dnssec-trigger project: > https://github.com/InfrastructureServices/dnssec-trigger-fedora > It's using tito. > > But I'm looking for a different way of

Re: CI projects in Copr

Hello Petr, On Thu, Aug 24, 2017 at 1:35 PM, Petr Stodulka 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 > >>

Re: CI projects in Copr

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

Re: CI projects in Copr

On 23/08/17 04:46 AM, Miroslav Suchý wrote: > Hi, > I am gathering informations about various use of CI with Copr. Do you > use Copr for building packages for nightlies? For building packages > before pull request is merged? Do you have your set up described > somewhere? What is the name of your

Re: CI projects in Copr

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:

Re: CI projects in Copr

Hi, We are making daily builds of Anaconda in Copr for Rawhide[1] and actual Fedora[2]. These daily builds are used for our other test suites. [1]: https://copr.fedorainfracloud.org/coprs/g/rhinstaller/Anaconda/ [2]: https://copr.fedorainfracloud.org/coprs/g/rhinstaller/Anaconda-dev el/ On

Re: CI projects in Copr

Hi, As the maintainer of the Pantheon DE components and elementary apps, I have a setup that runs "nightly" builds of 59 of those packages in the "decathorpe/elementary-nightly" COPR repository for all supported fedora releases. This "CI-like" setup helps me catch upstream changes (that warrant

Re: CI projects in Copr

Hi, I'm using Copr for build on commit for dnssec-trigger project: https://github.com/InfrastructureServices/dnssec-trigger-fedora It's using tito. But I'm looking for a different way of doing this. Especially when I work on some upstream project and I don't want to force them to include tito.

CI projects in Copr

Hi, I am gathering informations about various use of CI with Copr. Do you use Copr for building packages for nightlies? For building packages before pull request is merged? Do you have your set up described somewhere? What is the name of your project? Please let me know. Either here or via