public inbox for [email protected]
help / color / mirror / Atom feedfeature/master/ci [was Re: Detecting test failures reported as warnings]
15+ messages / 3 participants
[nested] [flat]
* feature/master/ci [was Re: Detecting test failures reported as warnings]
@ 2020-08-27 17:20 Chapman Flack <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Chapman Flack @ 2020-08-27 17:20 UTC (permalink / raw)
To: [email protected]
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: feature/master/ci [was Re: Detecting test failures reported as warnings]
@ 2020-08-27 19:32 Kartik Ohri <[email protected]>
parent: Chapman Flack <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Kartik Ohri @ 2020-08-27 19:32 UTC (permalink / raw)
To: Chapman Flack <[email protected]>; +Cc: [email protected]
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Travis and AppVeyor continuous integration [Re: feature/master/ci]
@ 2020-08-27 20:25 Chapman Flack <[email protected]>
parent: Kartik Ohri <[email protected]>
0 siblings, 2 replies; 15+ messages in thread
From: Chapman Flack @ 2020-08-27 20:25 UTC (permalink / raw)
To: Kartik Ohri <[email protected]>; +Cc: [email protected]
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]
@ 2020-08-27 21:27 Kartik Ohri <[email protected]>
parent: Chapman Flack <[email protected]>
1 sibling, 0 replies; 15+ messages in thread
From: Kartik Ohri @ 2020-08-27 21:27 UTC (permalink / raw)
To: Chapman Flack <[email protected]>; +Cc: [email protected]
Hi!
> > 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.
>
I have instructions for debug builds in the PR description as well.
Regards,
Kartik
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]
@ 2020-08-29 07:25 Thomas Hallgren <[email protected]>
parent: Chapman Flack <[email protected]>
1 sibling, 2 replies; 15+ messages in thread
From: Thomas Hallgren @ 2020-08-29 07:25 UTC (permalink / raw)
To: Chapman Flack <[email protected]>; +Cc: Kartik Ohri <[email protected]>; [email protected]
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 <[email protected]> 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
>
>
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]
@ 2020-08-29 07:32 Thomas Hallgren <[email protected]>
parent: Thomas Hallgren <[email protected]>
1 sibling, 0 replies; 15+ messages in thread
From: Thomas Hallgren @ 2020-08-29 07:32 UTC (permalink / raw)
To: Chapman Flack <[email protected]>; +Cc: Kartik Ohri <[email protected]>; [email protected]
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 <[email protected]> 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 <[email protected]> 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
>>
>>
>>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]
@ 2020-08-29 08:35 Kartik Ohri <[email protected]>
parent: Thomas Hallgren <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Kartik Ohri @ 2020-08-29 08:35 UTC (permalink / raw)
To: [email protected]; +Cc: Chapman Flack <[email protected]>; [email protected]
Hi!
On Sat, Aug 29, 2020 at 12:55 PM Thomas Hallgren <[email protected]> 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?
>
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]
@ 2020-08-29 13:10 Chapman Flack <[email protected]>
parent: Kartik Ohri <[email protected]>
0 siblings, 2 replies; 15+ messages in thread
From: Chapman Flack @ 2020-08-29 13:10 UTC (permalink / raw)
To: Kartik Ohri <[email protected]>; [email protected]; +Cc: [email protected]
On 08/29/20 04:35, Kartik Ohri wrote:
> Hi!
> On Sat, Aug 29, 2020 at 12:55 PM Thomas Hallgren <[email protected]> wrote:
>> 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?
>>
>
> 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.
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]
@ 2020-08-29 13:34 Kartik Ohri <[email protected]>
parent: Chapman Flack <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Kartik Ohri @ 2020-08-29 13:34 UTC (permalink / raw)
To: Chapman Flack <[email protected]>; +Cc: [email protected]; [email protected]
On Sat, Aug 29, 2020 at 6:40 PM Chapman Flack <[email protected]> wrote:
> On 08/29/20 04:35, Kartik Ohri wrote:
> > Hi!
> > On Sat, Aug 29, 2020 at 12:55 PM Thomas Hallgren <[email protected]> wrote:
> >> 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?
> >>
> >
> > 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.
>
> 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.
>
>
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.
> 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
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]
@ 2020-08-29 13:40 Kartik Ohri <[email protected]>
parent: Kartik Ohri <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Kartik Ohri @ 2020-08-29 13:40 UTC (permalink / raw)
To: Chapman Flack <[email protected]>; +Cc: [email protected]; [email protected]
On Sat, Aug 29, 2020 at 7:04 PM Kartik Ohri <[email protected]> wrote:
> On Sat, Aug 29, 2020 at 6:40 PM Chapman Flack <[email protected]>
> wrote:
>
>> On 08/29/20 04:35, Kartik Ohri wrote:
>> > Hi!
>> > On Sat, Aug 29, 2020 at 12:55 PM Thomas Hallgren <[email protected]>
>> wrote:
>> >> 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?
>> >>
>> >
>> > 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.
>>
>> 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.
>>
>>
> 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.
>
>
>> 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
>>
>
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]
@ 2020-08-29 18:30 Chapman Flack <[email protected]>
parent: Chapman Flack <[email protected]>
1 sibling, 2 replies; 15+ messages in thread
From: Chapman Flack @ 2020-08-29 18:30 UTC (permalink / raw)
To: Kartik Ohri <[email protected]>; [email protected]; +Cc: [email protected]
On 08/29/20 09:10, Chapman Flack wrote:
> 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?
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]
@ 2020-08-29 18:41 Chapman Flack <[email protected]>
parent: Chapman Flack <[email protected]>
1 sibling, 0 replies; 15+ messages in thread
From: Chapman Flack @ 2020-08-29 18:41 UTC (permalink / raw)
To: Kartik Ohri <[email protected]>; [email protected]; +Cc: [email protected]
On 08/29/20 14:30, Chapman Flack wrote:
> 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.
> ...
> 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.
#289 is merged now.
Regards,
-Chap
> 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.)
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]
@ 2020-08-30 05:34 Thomas Hallgren <[email protected]>
parent: Chapman Flack <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Thomas Hallgren @ 2020-08-30 05:34 UTC (permalink / raw)
To: Chapman Flack <[email protected]>; +Cc: Kartik Ohri <[email protected]>; [email protected]
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
On Sat, 29 Aug 2020 at 20:30, Chapman Flack <[email protected]> wrote:
> On 08/29/20 09:10, Chapman Flack wrote:
> > 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?
>
>
> 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
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]
@ 2020-08-30 12:46 Chapman Flack <[email protected]>
parent: Thomas Hallgren <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Chapman Flack @ 2020-08-30 12:46 UTC (permalink / raw)
To: [email protected]; +Cc: Kartik Ohri <[email protected]>; [email protected]
On 08/30/20 01:34, Thomas Hallgren wrote:
> 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.
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]
@ 2020-08-31 11:33 Thomas Hallgren <[email protected]>
parent: Chapman Flack <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Thomas Hallgren @ 2020-08-31 11:33 UTC (permalink / raw)
To: Chapman Flack <[email protected]>; +Cc: Kartik Ohri <[email protected]>; [email protected]
I've added AppVeyor as well (as an app).
Best,
Thomas
On Sun, 30 Aug 2020 at 14:46, Chapman Flack <[email protected]> wrote:
> On 08/30/20 01:34, Thomas Hallgren wrote:
> > 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.
>
> 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
>
^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2020-08-31 11:33 UTC | newest]
Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-08-27 17:20 feature/master/ci [was Re: Detecting test failures reported as warnings] Chapman Flack <[email protected]>
2020-08-27 19:32 ` Kartik Ohri <[email protected]>
2020-08-27 20:25 ` Travis and AppVeyor continuous integration [Re: feature/master/ci] Chapman Flack <[email protected]>
2020-08-27 21:27 ` Re: Travis and AppVeyor continuous integration [Re: feature/master/ci] Kartik Ohri <[email protected]>
2020-08-29 07:25 ` Re: Travis and AppVeyor continuous integration [Re: feature/master/ci] Thomas Hallgren <[email protected]>
2020-08-29 07:32 ` Re: Travis and AppVeyor continuous integration [Re: feature/master/ci] Thomas Hallgren <[email protected]>
2020-08-29 08:35 ` Re: Travis and AppVeyor continuous integration [Re: feature/master/ci] Kartik Ohri <[email protected]>
2020-08-29 13:10 ` Re: Travis and AppVeyor continuous integration [Re: feature/master/ci] Chapman Flack <[email protected]>
2020-08-29 13:34 ` Re: Travis and AppVeyor continuous integration [Re: feature/master/ci] Kartik Ohri <[email protected]>
2020-08-29 13:40 ` Re: Travis and AppVeyor continuous integration [Re: feature/master/ci] Kartik Ohri <[email protected]>
2020-08-29 18:30 ` Re: Travis and AppVeyor continuous integration [Re: feature/master/ci] Chapman Flack <[email protected]>
2020-08-29 18:41 ` Re: Travis and AppVeyor continuous integration [Re: feature/master/ci] Chapman Flack <[email protected]>
2020-08-30 05:34 ` Re: Travis and AppVeyor continuous integration [Re: feature/master/ci] Thomas Hallgren <[email protected]>
2020-08-30 12:46 ` Re: Travis and AppVeyor continuous integration [Re: feature/master/ci] Chapman Flack <[email protected]>
2020-08-31 11:33 ` Re: Travis and AppVeyor continuous integration [Re: feature/master/ci] Thomas Hallgren <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox