Subject: feature/master/ci [was Re: Detecting test failures reported as warnings]

From: Chapman Flack <[email-masked]>
Date: Thu, 27 Aug 2020 13:20:34 -0400

Hi Kartik,

When convenient, could you merge PR #16 into your feature/master/ci
branch, and then open a pull request for that branch in the main
repository?

It has just completed builds in Travis and Appveyor, with just one
failed job each. In Travis it was a spurious failure where MacPorts
sometimes fails to find the openssl package, and as I mentioned earlier[1],
once your plugin work is integrated, we should not even need that
MacPorts package.

The one job that has been failing very consistently in Appveyor is
PG 10 MSVC, and I suspect there is an actual bug there I need to find,
not a problem with CI. So I think the CI is ready to go.

When you open the PR for it, please describe in the PR notes anything
that needs to be done in the main repo when the PR is merged. I.e., will
it just start working because the files are there, or do some administrative
actions need to be taken, registering with Travis / Appveyor, etc.

Then I will merge that PR relatively promptly (I generally try to let
them breathe for a day at least), and you can rebase your plugin branch
over it then.

Regards,
-Chap

[1] https://www.postgresql.org/message-id/5F470163.2080300%40anastigmatix.net

---

From: Kartik Ohri <[email-masked]>
Date: Fri, 28 Aug 2020 01:02:13 +0530

Hi!
I have opened a PR to merge the CI. 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 ?
Thanks.
Regards,
Kartik

---

From: Chapman Flack <[email-masked]>
Date: Thu, 27 Aug 2020 16:25:04 -0400

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

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

---

From: Kartik Ohri <[email-masked]>
Date: Fri, 28 Aug 2020 02:57:53 +0530

Hi!

> If you're up for it, yes, that would be good information to have in one
I have instructions for debug builds in the PR description as well.
Regards,
Kartik

---

From: Thomas Hallgren <[email-masked]>
Date: Sat, 29 Aug 2020 09:25:17 +0200

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

---

From: Thomas Hallgren <[email-masked]>
Date: Sat, 29 Aug 2020 09:32:27 +0200

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

---

From: Kartik Ohri <[email-masked]>
Date: Sat, 29 Aug 2020 14:05:35 +0530

Hi!
On Sat, Aug 29, 2020 at 12:55 PM Thomas Hallgren <[email-masked]> wrote:

> my repositories, and why don't they offer a read-only alternative?
>

Travis recommends all repositories access but that can be easily restricted
to a single repository. Once, the application has been authorized. Github
will ask whether to install in a single repository or all.

Also, I checked which permissions the Travis app installed on my repo has.
The current Travis App has the write access to checks, commit statuses,
deployments, and repository hooks. The first three make sense but I am not
sure about the role of repository hooks. For what it's worth, AppVeyor
requires write access to only checks, commit statuses. However, in the
future I think we would like to deploy using Travis CI, Chap will be able
to provide more details in this case I believe. So, the only extra write
permission is for repository hooks which seems to be harmless but I may be
wrong.

Regards,
Kartik

---

From: Chapman Flack <[email-masked]>
Date: Sat, 29 Aug 2020 09:10:27 -0400

On 08/29/20 04:35, Kartik Ohri wrote:
> requires write access to only checks, commit statuses.

I will admit to a bit of a shock yesterday when, out of curiosity, I went
to https://travis-ci.com/plans and clicked "SET UP YOUR OPEN SOURCE PROJECT
NOW" and was immediately faced with a GitHub "Authorize Travis CI" dialog
requesting:

=====
Organizations and teams
Read-only access

This application will be able to read your organization, team membership,
and private project boards.

Repositories
Public and private

This application will be able to read and write all public and private
repository data. This includes the following:

    Code
    Issues
    Pull requests
    Wikis
    Settings
    Webhooks and services
    Deploy keys
    Collaboration invites

Personal user data
Email addresses (read-only)

This application will be able to read your private email addresses.
=====

The "Cancel" button is still smoking from how hard I hit it.

But I think that must have been their older, pre-GitHub-App, signup
process. I am not sure why they still have a working link that goes there.

Thomas, if their current permission requests, when configured as a
GitHub App, are as Kartik describes, and can be limited to the PL/Java
repo only, would that answer your concerns (even if not perfectly,
perhaps acceptably)?

It seems to me also that such concerns can have a "duration" dimension:
if even their more limited, app-based, permissions are not entirely
satisfactory, perhaps they would be tolerable for a limited period
(a calendar quarter, perhaps) to immediately reap the benefits of
Kartik's work while affording time to explore migrating the scripts
to Github Actions without a rush?

As I mentioned earlier, I suspect the migration would be fairly
straightforward. Kartik's GSoC-sponsored period concludes this weekend,
however. and migrating it all to GitHub Actions is probably not quite
*that* straightforward.

Regards,
-Chap

---

From: Kartik Ohri <[email-masked]>
Date: Sat, 29 Aug 2020 19:04:32 +0530

> process. I am not sure why they still have a working link that goes there.
Yes, this is indeed the case. I created a new account and followed the same
procedure as Chap and got the permissions as he mentioned. However, when I
tried to install Travis through the marketplace I got the permissions as I
mentioned in the mail earlier today.

---

From: Kartik Ohri <[email-masked]>
Date: Sat, 29 Aug 2020 19:10:56 +0530

On Sat, Aug 29, 2020 at 7:04 PM Kartik Ohri <[email-masked]> wrote:

> Yes, this is indeed the case. I created a new account and followed the
> same procedure as Chap and got the permissions as he mentioned. However,
> when I tried to install Travis through the marketplace I got the
> permissions as I mentioned in the mail earlier today.
>
>
To investigate further, I tried it with AppVeyor as well. And I got a lot
more permissions requests than from the marketplace. The footer that
mentioned it was using OAuth. So, it seems that both Travis and AppVeyor
have a Github and OAuth app. The Github apps require less permissions than
the OAuth ones. To install an app as Github App, install it using the
Github marketplace.

Regards,
Kartik

---

From: Chapman Flack <[email-masked]>
Date: Sat, 29 Aug 2020 14:30:48 -0400

> to Github Actions without a rush?

Not having heard back from Thomas yet, I propose the following:

I will merge PR #289. This will bring the current, working Travis and
AppVeyor configurations into the git history. No CI will happen, of course,
before the corresponding apps are set up.

If Thomas is immovably opposed to setting up the apps, even with their
more limited permissions, for one repository only, perhaps for a limited
period, then the working Travis and AppVeyor configurations will be in
the history anyway, and can serve as starting points for GitHub Actions
workflows to be developed as time permits.

In any case, Kartik, once I have merged #289, you will be able to rebase
feature/master/pgxs over master as feature/master/pgxs-2 and make a new
pull request to supersede #291.

This should happen after the problem you just noticed in
getPgConfigPropertyAsList has been fixed (and a unit test added to
keep it fixed), and after adding -Dpljava.libjvmdefault on the mvn
build commands and removing pljava.libjvm_location from the jshell
test scripts, to confirm that the value gets correctly compiled in.
(The tests, of course, will not run in the main repo. but will still
run in yours.)

Regards,
-Chap

---

From: Chapman Flack <[email-masked]>
Date: Sat, 29 Aug 2020 14:41:07 -0400

On 08/29/20 14:30, Chapman Flack wrote:
> ...

#289 is merged now.

Regards,
-Chap

---

From: Thomas Hallgren <[email-masked]>
Date: Sun, 30 Aug 2020 07:34:26 +0200

I had no idea Travis-CI could be installed as an app with access to
selected repositories. Thanks for pointing that out. As that addresses my
concerns, it's now installed for the tada organization and has access to
the pljava repo.

Regards,
Thomas

---

From: Chapman Flack <[email-masked]>
Date: Sun, 30 Aug 2020 08:46:36 -0400

> concerns, it's now installed for the tada organization and has access to

Many thanks for that. I did begin some experimenting with GitHub Actions
in my own fork last night, and it seems promising, but it will be helpful
to have the existing Travis-CI support working while continuing down
that road.

Do you have a verdict on AppVeyor? I think it has an app-based setup
similar to Travis, perhaps with even fewer permissions, according to
Kartik's earlier mail. The current configuration uses AppVeyor for
the Windows MSVC and Windows MinGW-w64 builds.

It was amidst the Windows details in GitHub Actions that I walked away
in exhaustion last night. But Windows details exhaust me on a good day.
Perhaps Kartik will be interested in lending a hand with that part
after the official end of GSoC. We might both welcome a chance to do
some other things and then come back to it, though. Maybe even other
PL/Java things. If the completed AppVeyor configuration were working,
at least the CI coverage he has already achieved would all be in place.

Regards,
-Chap

---

From: Thomas Hallgren <[email-masked]>
Date: Mon, 31 Aug 2020 13:33:33 +0200

I've added AppVeyor as well (as an app).

Best,
Thomas