Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]

On 08/29/20 04:35, Kartik Ohri wrote:
> Hi!
> On Sat, Aug 29, 2020 at 12:55 PM Thomas Hallgren <thomas(at)tada(dot)se> 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