Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kBvM0-0007rC-De for pljava-dev@arkaria.postgresql.org; Sat, 29 Aug 2020 07:32:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kBvLz-0001BD-Cb for pljava-dev@arkaria.postgresql.org; Sat, 29 Aug 2020 07:32:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kBvLz-0001B6-62 for pljava-dev@lists.postgresql.org; Sat, 29 Aug 2020 07:32:47 +0000 Received: from mail-lj1-f195.google.com ([209.85.208.195]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kBvLs-00049v-03 for pljava-dev@lists.postgresql.org; Sat, 29 Aug 2020 07:32:46 +0000 Received: by mail-lj1-f195.google.com with SMTP id h19so1264973ljg.13 for ; Sat, 29 Aug 2020 00:32:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=IfJGcdYxjT2bI9idnFyJ+0MHqM25hvIkwnd/jAF+aG8=; b=iV+Usfw/5qNN6jQE2s+3P31hltMjNfinqGIlFOj07+Z6uk2BXFwSZyJoZuGNDha7Ho NHr553lMQAx9tAbG9NxKR9ud8nvNMjW9+IEZZjQ1nYYEn0Ns3xe4fBNcRP0Dflh6wsLS JJb0L+uiXYDqPANiEeBXLywEkiTRW5U8leyuLr+rLCZi1VJlvsO7lWE37BFOr7qXfY0Q 48bZg4ieexLtNj9G6NxRari40761LGM6Svh7aY6DB3p1lFWdcUYJNZdAjLvloljfInwv LKbjfi7XYup7ZDF1oa7fg+fb6s1+ZyzsCpv3ssdJUWiqRrOdMNbGTiNZyyxTQrPkMYDN 1XIA== X-Gm-Message-State: AOAM533RN6BY8nrjCJuKCFJBxNO03/JJnfm/hI4zNutOpgC4UTDXZ0jW 4zciBClcrKo4aQFV0zp6lhokT9LvCWhIrlu35nuBhzsLbb4= X-Google-Smtp-Source: ABdhPJw/oGUbtXkHYLdhdc2A9YYcA2koCfKITjzo2gcDsCd37KsSjIBHPSwoN6z6Swhe97ozLqK5MaGmWNZo4KyRr4s= X-Received: by 2002:a2e:320c:: with SMTP id y12mr990479ljy.399.1598686358102; Sat, 29 Aug 2020 00:32:38 -0700 (PDT) MIME-Version: 1.0 References: <5EC17E17.7070002@anastigmatix.net> <5ED270BA.9010001@anastigmatix.net> <5ED3D488.1010401@anastigmatix.net> <5ED474CA.3000106@anastigmatix.net> <5ED4EA10.4030801@anastigmatix.net> <5ED7E74B.9020800@anastigmatix.net> <5EDA576E.2000204@anastigmatix.net> <5EDBA5D9.8090506@anastigmatix.net> <5EE7AE8C.2040201@anastigmatix.net> <5EEA6F85.9040009@anastigmatix.net> <5F063C86.3070301@anastigmatix.net> <5F47EB62.2060306@anastigmatix.net> <5F4816A0.8020208@anastigmatix.net> In-Reply-To: Reply-To: thomas@tada.se From: Thomas Hallgren Date: Sat, 29 Aug 2020 09:32:27 +0200 Message-ID: Subject: Re: Travis and AppVeyor continuous integration [Re: feature/master/ci] To: Chapman Flack Cc: Kartik Ohri , pljava-dev@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000007b665b05adff2cc2" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000007b665b05adff2cc2 Content-Type: text/plain; charset="UTF-8" Forgot to answer on AppVeyor. While AppVeyor doesn't seem to have the write permission requirement, I still think GitHub Actions is a better choice. I run CI for windows using them on a regular basis and I haven't had any issues with it. It's also nice to have all the CI workflow in one place, written with one syntax. Regards, Thomas On Sat, 29 Aug 2020 at 09:25, Thomas Hallgren wrote: > Hi Chap, > > I'm somewhat reluctant to TravisCI due to its requirement for write > permissions to *all* my repositories and associated data. Why would anyone > grant an external CI service such permissions just to handle CI of *one* of > my repositories, and why don't they offer a read-only alternative? I know > nothing about how secure the organization behind the service is and I'm > surprised so few react to this. I don't know, perhaps I'm over cautious and > perhaps I've misunderstood (if so, please explain what I'm missing) but so > far, I've chosen to not use TravisCI. > > Regards, > Thomas > > On Thu, 27 Aug 2020 at 22:25, Chapman Flack wrote: > >> On 08/27/20 15:32, Kartik Ohri wrote: >> > I have opened a PR to merge the CI. >> >> Thanks! >> >> > Should I add instructions to launch a >> > manual build to ssh into the different build environments for the >> purpose >> > of debugging in the PR description as well ? >> >> If you're up for it, yes, that would be good information to have in one >> place. >> >> >> For Thomas, if you're watching: >> >> The description for pull request #289 [1] includes details on >> administrative setup with Travis and AppVeyor in order for the >> CI setup in the pull request to become operational. >> >> Would you like to do that part? Can/should I do that part? >> >> Earlier, you mentioned a possible preference for GitHub Actions. >> The current proposed configuration uses Travis for testing x86_64 >> Ubuntu and Mac OS, and AppVeyor for x86_64 Windows (building with >> MSVC and with MinGW-w64). >> >> I see that Travis has added some level of Windows support, so that >> it might be possible at some future time to migrate the Windows tests >> there and consolidate, and I see GitHub Actions also claiming support >> for all three platforms. >> >> The two files .travis.yml [2] and appveyor.yml [3] are recognizably >> small mutations of each other, suggesting what is probably the modest >> effort of migrating either one or both to another service that comes >> to be preferred, or even just to compare. >> >> I would propose to register with Travis and AppVeyor for now, and >> merge #289 as-is, maintaining the option to migrate to another >> service if desired in the future. >> >> Regards, >> -Chap >> >> >> >> [1] https://github.com/tada/pljava/pull/289 >> [2] https://github.com/tada/pljava/blob/943152b/.travis.yml >> [3] https://github.com/tada/pljava/blob/943152b/appveyor.yml >> >> >> --0000000000007b665b05adff2cc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forgot to answer on AppVeyor.

While AppVeyor doesn't seem= to have the write permission requirement, I still think GitHub Actions is = a better choice. I run CI for windows using them on a regular basis and I h= aven't had any issues with it. It's also nice to have all the CI wo= rkflow in one place, written with one syntax.

Regards,
Thomas

On S= at, 29 Aug 2020 at 09:25, Thomas Hallgren <thomas@tada.se> wrote:
Hi Chap,

I'm somewhat relucta= nt to TravisCI due to its requirement for write permissions to *all* my rep= ositories and associated data. Why would anyone grant an external CI servic= e such permissions just to handle CI of *one* of my repositories, and why d= on't they offer a read-only alternative? I know nothing about how secur= e the organization behind the service is and I'm surprised so few react= to this. I don't know, perhaps I'm over cautious=C2=A0and perhaps = I've misunderstood (if so, please explain what I'm missing) but so = far, I've chosen to not use TravisCI.

Regards,
Thomas
<= /div>
O= n Thu, 27 Aug 2020 at 22:25, Chapman Flack <chap@anastigmatix.net> wrote:
On 08/27/20 15:32, Kart= ik Ohri wrote:
> I have opened a PR to merge the CI.

Thanks!

> Should I add instructions to launch a
> manual build to ssh into the different build environments for the purp= ose
> of debugging in the PR description as well ?

If you're up for it, yes, that would be good information to have in one= place.


For Thomas, if you're watching:

The description for pull request #289 [1] includes details on
administrative setup with Travis and AppVeyor in order for the
CI setup in the pull request to become operational.

Would you like to do that part? Can/should I do that part?

Earlier, you mentioned a possible preference for GitHub Actions.
The current proposed configuration uses Travis for testing x86_64
Ubuntu and Mac OS, and AppVeyor for x86_64 Windows (building with
MSVC and with MinGW-w64).

I see that Travis has added some level of Windows support, so that
it might be possible at some future time to migrate the Windows tests
there and consolidate, and I see GitHub Actions also claiming support
for all three platforms.

The two files .travis.yml [2] and appveyor.yml [3] are recognizably
small mutations of each other, suggesting what is probably the modest
effort of migrating either one or both to another service that comes
to be preferred, or even just to compare.

I would propose to register with Travis and AppVeyor for now, and
merge #289 as-is, maintaining the option to migrate to another
service if desired in the future.

Regards,
-Chap



[1] https://github.com/tada/pljava/pull/289
[2] https://github.com/tada/pljava/blob/94315= 2b/.travis.yml
[3] https://github.com/tada/pljava/blob/9431= 52b/appveyor.yml


--0000000000007b665b05adff2cc2--