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 1kBvF4-0007Y6-2V for pljava-dev@arkaria.postgresql.org; Sat, 29 Aug 2020 07:25:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kBvF1-0006sO-Vl for pljava-dev@arkaria.postgresql.org; Sat, 29 Aug 2020 07:25:35 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kBvF1-0006sH-Kv for pljava-dev@lists.postgresql.org; Sat, 29 Aug 2020 07:25:35 +0000 Received: from mail-lj1-f170.google.com ([209.85.208.170]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kBvEw-0001MB-PF for pljava-dev@lists.postgresql.org; Sat, 29 Aug 2020 07:25:34 +0000 Received: by mail-lj1-f170.google.com with SMTP id e11so1298495ljn.6 for ; Sat, 29 Aug 2020 00:25:30 -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=uAHZS6uQlCrWYQupnHzsxhz3XvpSH2CdXnhdRJWPcQQ=; b=DMOQE4zVMNawDpfBf+Tslq0OfH7Ux42+9ZKCOkAHfxbV7CeWDkB2YfxAl13EBxGcwb RPEH7mUylxWoq7SUdy1vdTW30iKIsig5KrWbtUKTaJHYf6eJedYH6ZlJMrn5M9aCbpX8 eaavjlSXP3pc5wypNXQ5diqxjRCwEE3mZEW8s1ElvF9srJS3CZ6h0aciOtuLPTqRkUkQ EsF5JuLKxy24p6nQbq54spsMC9Nga90SJOCLQB0Qm/6IZ4y3I3bH6RZsDnVin73sCDCt RnYKYx2QzSxhya5zagyDDgjBt78438vRXTCMFlfzVrpJ9cBkDQWLIPAtrnyxlbUOjGq+ A05w== X-Gm-Message-State: AOAM533hWah2PduXJvh9yKfxIAvoCfSRAGWxeENhBIyGbKM5iV0w0qOb TcYy1t5gDREMmiN35NrlToy3xuM49WeL4GzASLU= X-Google-Smtp-Source: ABdhPJyKl2kxAkLUVPwdEjki8RVPFGKBWA2olKhnaO23RMhvwgukZxPlEPdw1dzdyhvFfkSAaaAaXT2HeyahuaTzoG0= X-Received: by 2002:a05:651c:314:: with SMTP id a20mr956047ljp.434.1598685928838; Sat, 29 Aug 2020 00:25:28 -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: <5F4816A0.8020208@anastigmatix.net> Reply-To: thomas@tada.se From: Thomas Hallgren Date: Sat, 29 Aug 2020 09:25:17 +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="000000000000e55a4205adff126c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000e55a4205adff126c Content-Type: text/plain; charset="UTF-8" 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 > > > --000000000000e55a4205adff126c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chap,

I'm somewhat reluctant to TravisCI due to its re= quirement for write permissions to *all* my repositories and associated dat= a. Why would anyone grant an external CI service such permissions just to h= andle CI of *one* of my repositories, and why don't they offer a read-o= nly alternative? I know nothing about how secure the organization behind th= e 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 s= o, please explain what I'm missing) but so far, I've chosen to not = use TravisCI.

Regards,
Thomas

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, 27 Aug 2020 at 22:25, Chapman = Flack <chap@anastigmatix.net> 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 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


--000000000000e55a4205adff126c--