[
https://issues.apache.org/jira/browse/FLINK-37770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
david radley updated FLINK-37770:
---------------------------------
Description:
Implement [FLIP
518]([https://cwiki.apache.org/confluence/display/FLINK/FLIP-518%3A+Introduce+a+community+review+process])
Investigations are documented
[https://github.com/actions/github-script/discussions/598] In summary
* I tried using\{{ pull_request_review failed to have enough permissions to
get the collaborators or write. label due to permissions from a fork}}
* I tried using\{{ pull_request_review then using github actions to use github
caching to stash the PR review content into the cache then have a cron
gitaction pick up the cache. The cron gitaction has enough permissions.
Unfortunately the github. Caches are associated with e branches and we are in a
refs/pull/7/merge (for pr 7). So the cron job could not see the cache}}
* {{I tried using pull_request_target. This only works on main branch and is
deemed insecure.}}{{ }}
In the absence of a way to trigger the the label based on a review, I have
written a github cron job to look for all open PRs with reviews.
* There is a graphql query we can use to get all open PRs and associated
reviews. This is good but is limited to 100 return items, so I need to have
paging logic to get all the PRs.
* I then need to look at the reviews, currently there are less then 100
reviews per PR, but I have added and tested paging logic for the reviews
* The reviews needs to be normalised to have only the latests review from each
reviewer
* Then we need to find out is the reviewed is a committer or not and then
apply the logic in the flip to label the PR, the simplest way of doing this is
to issue a rest call to get whether a use has push permission to the repo for
each review
Optimisations
* to reduce the rest calls for collaborators, we could
**
*** have a github cron job that polls the repos collaborators and creates a
file in github cache that could be brought in and queried.
*** issue stash any collaborators we find and whether they have push access in
a local file so we only check each reviewers once per run. I am looking at this
option
* check the review time and see if we need to do anything. If all reviews
are older than the last time we ran then we do not need to do anything.
The PR is currently being tested locally, will share when testing complete.
Notes:
I am implementing the change in separate bash files as I do not have the
appropriate permission with the flink repo - I can test each piece with other
repos to check they are working as expected.
The files I create are in the current folder - I could create them in another
'data' folder if there is a preference to do this.
was:
Implement [FLIP
518]([https://cwiki.apache.org/confluence/display/FLINK/FLIP-518%3A+Introduce+a+community+review+process])
Investigations are documented
[https://github.com/actions/github-script/discussions/598] In summary
* I tried using{{ pull_request_review failed to have enough permissions to get
the collaborators or write. label due to permissions from a fork}}
* I tried using{{ pull_request_review then using github actions to use github
caching to stash the PR review content into the cache then have a cron
gitaction pick up the cache. The cron gitaction has enough permissions.
Unfortunately the github. Caches are associated with e branches and we are in a
refs/pull/7/merge (for pr 7). So the cron job could not see the cache}}
* {{I tried using pull_request_target. This only works on main branch and is
deemed insecure.}}{{ }}
In the absence of a way to trigger the the label based on a review, I have
written a github cron job to look for all open PRs with reviews.
* There is a graphql query we can use to get all open PRs and associated
reviews. This is good but is limited to 100 return items, so I need to have
paging logic to get all the PRs.
* I then need to look at the reviews, currently there are less then 100
reviews per PR, but I have added and tested paging logic for the reviews
* The reviews needs to be normalised to have only the latests review from each
reviewer
* Then we need to find out is the reviewed is a committer or not and then
apply the logic in the flip to label the PR, the simplest way of doing this is
to issue a rest call to get whether a use has push permission to the repo for
each review
*
Optimisations
* to reduce the rest calls for collaborators, we could
**
*** have a github cron job that polls the repos collaborators and creates a
file in github cache that could be brought in and queried.
*** issue stash any collaborators we find and whether they have push access in
a local file so we only check each reviewers once per run. I am looking at this
option
* check the review time and see if we need to do anything. If all reviews
are older than the last time we ran then we do not need to do anything.
The PR is currently being tested locally, will share when testing complete.
> FLIP-518: Introduce a community review process
> ----------------------------------------------
>
> Key: FLINK-37770
> URL: https://issues.apache.org/jira/browse/FLINK-37770
> Project: Flink
> Issue Type: New Feature
> Reporter: david radley
> Priority: Major
>
> Implement [FLIP
> 518]([https://cwiki.apache.org/confluence/display/FLINK/FLIP-518%3A+Introduce+a+community+review+process])
> Investigations are documented
> [https://github.com/actions/github-script/discussions/598] In summary
> * I tried using\{{ pull_request_review failed to have enough permissions to
> get the collaborators or write. label due to permissions from a fork}}
> * I tried using\{{ pull_request_review then using github actions to use
> github caching to stash the PR review content into the cache then have a cron
> gitaction pick up the cache. The cron gitaction has enough permissions.
> Unfortunately the github. Caches are associated with e branches and we are in
> a refs/pull/7/merge (for pr 7). So the cron job could not see the cache}}
> * {{I tried using pull_request_target. This only works on main branch and is
> deemed insecure.}}{{ }}
> In the absence of a way to trigger the the label based on a review, I have
> written a github cron job to look for all open PRs with reviews.
> * There is a graphql query we can use to get all open PRs and associated
> reviews. This is good but is limited to 100 return items, so I need to have
> paging logic to get all the PRs.
> * I then need to look at the reviews, currently there are less then 100
> reviews per PR, but I have added and tested paging logic for the reviews
> * The reviews needs to be normalised to have only the latests review from
> each reviewer
> * Then we need to find out is the reviewed is a committer or not and then
> apply the logic in the flip to label the PR, the simplest way of doing this
> is to issue a rest call to get whether a use has push permission to the repo
> for each review
> Optimisations
> * to reduce the rest calls for collaborators, we could
> **
> *** have a github cron job that polls the repos collaborators and creates a
> file in github cache that could be brought in and queried.
> *** issue stash any collaborators we find and whether they have push access
> in a local file so we only check each reviewers once per run. I am looking at
> this option
> * check the review time and see if we need to do anything. If all
> reviews are older than the last time we ran then we do not need to do
> anything.
> The PR is currently being tested locally, will share when testing complete.
> Notes:
> I am implementing the change in separate bash files as I do not have the
> appropriate permission with the flink repo - I can test each piece with other
> repos to check they are working as expected.
> The files I create are in the current folder - I could create them in
> another 'data' folder if there is a preference to do this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
