{"action":"created","issue":{"url":"https://api.github.com/repos/javafxports/openjdk-jfx/issues/8","repository_url":"https://api.github.com/repos/javafxports/openjdk-jfx","labels_url":"https://api.github.com/repos/javafxports/openjdk-jfx/issues/8/labels{/name}","comments_url":"https://api.github.com/repos/javafxports/openjdk-jfx/issues/8/comments","events_url":"https://api.github.com/repos/javafxports/openjdk-jfx/issues/8/events","html_url":"https://github.com/javafxports/openjdk-jfx/issues/8","id":302965200,"number":8,"title":"GitHub Bot","user":{"login":"brcolow","id":6589866,"avatar_url":"https://avatars1.githubusercontent.com/u/6589866?v=4","gravatar_id":"","url":"https://api.github.com/users/brcolow","html_url":"https://github.com/brcolow","followers_url":"https://api.github.com/users/brcolow/followers","following_url":"https://api.github.com/users/brcolow/following{/other_user}","gists_url":"https://api.github.com/users/brcolow/gists{/gist_id}","starred_url":"https://api.github.com/users/brcolow/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/brcolow/subscriptions","organizations_url":"https://api.github.com/users/brcolow/orgs","repos_url":"https://api.github.com/users/brcolow/repos","events_url":"https://api.github.com/users/brcolow/events{/privacy}","received_events_url":"https://api.github.com/users/brcolow/received_events","type":"User","site_admin":false},"labels":[{"id":878448809,"url":"https://api.github.com/repos/javafxports/openjdk-jfx/labels/housekeeping","name":"housekeeping","color":"fef2c0","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":18,"created_at":"2018-03-07T04:59:30Z","updated_at":"2018-03-31T13:18:53Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"As I have mentioned on the openjfx-dev mailing list, I believe running a simple bot will automate the process of getting contributions in the state where they are more likely to be accepted by upstream OpenJFX. My idea is:\r\n\r\nConfigure this GitHub repository to have a webhook for pull requests that points to a URL of the bot.\r\n\r\nUse the GitHub status API to add a status check which is managed by the bot. This is similar to how we currently have status checks for Travis CI and Appveyor.\r\n\r\nThe bot does a couple things:\r\n\r\n1.) Checks to see if the user who opened the PR has signed the OCA. We can keep a simple list of associations between github usernames and the name/email they signed the OCA under. The bot can post a comment on the PR asking the user if they have signed the OCA and if so under what name/email. If they reply they haven't signed it yet, the bot can instruct them how to do so.\r\n2.) Take the raw patch of the PR (the result of `git format-patch`) and convert it to a mercurial commit which can then be `hg import`ed into a local instance of the OpenJFX upstream mercurial repository.\r\n3.) Generate a webrev using the mercurial commit against OpenJFX upstream master.\r\n4.) Runs [jcheck](http://openjdk.java.net/projects/code-tools/jcheck/) against the mercurial commit/changeset.\r\n5.) Checks to see if this PR is associated with a JBS bug report and if so, links to it on the status page of that PR.\r\n\r\nThe status check will provide a link to a simple page that shows the OCA status, the mercurial patch, the webrev, jcheck results, and any linked JBS bug reports  (this is similar to how clicking on the Travis CI status check brings one to the Travis CI build for that PR).\r\n\r\nThe status of the status check will be set depending on:\r\n\r\n* Pending when we first receive the pull request event from the webhook.\r\n* If the user has not yet signed the OCA, the status is set to failed.\r\n* If the mercurial commit does not apply cleanly to OpenJFX upstream master, the status is set to failed.\r\n* If for some reason we can't generate the webrev, the status is set to failed.\r\n* If jcheck fails, the status is set to failed.\r\n* Otherwise, the status is set to successful.\r\n\r\nGitHub status API:\r\n\r\nhttps://developer.github.com/v3/repos/statuses/\r\n\r\nGithub Pull request webhook event:\r\n\r\nhttps://developer.github.com/v3/activity/events/types/#pullrequestevent\r\n\r\nAt first I thought we could easily use some type of \"serverless\" compute like Amazon Lambda, but having to interact with a mercurial repository of OpenJFX complicates things and I think things will be much easier having an application running on a server. We can do something very simple in Java, say, using Jersey. It would expose one REST endpoint (that github will send the pull request events to via the webhook).\r\n\r\nThe other thing I wanted to mention is we could expand upon the basic idea to include needing say N reviews from a person with OpenJFX contributor status, and the status check could mandate that.\r\n\r\nWhat do you all think? Is it worth it? If I coded up a simple prototype would it be useful? Is there a server it could be hosted on? Just want to get the ball rolling on this and start the conversation. As most of you know, we are all still in \"negotiations\" with the OpenJFX team and how best this repository can foster contributions that will end up in OpenJFX."},"comment":{"url":"https://api.github.com/repos/javafxports/openjdk-jfx/issues/comments/377692452","html_url":"https://github.com/javafxports/openjdk-jfx/issues/8#issuecomment-377692452","issue_url":"https://api.github.com/repos/javafxports/openjdk-jfx/issues/8","id":377692452,"user":{"login":"ararunprasad","id":3874763,"avatar_url":"https://avatars2.githubusercontent.com/u/3874763?v=4","gravatar_id":"","url":"https://api.github.com/users/ararunprasad","html_url":"https://github.com/ararunprasad","followers_url":"https://api.github.com/users/ararunprasad/followers","following_url":"https://api.github.com/users/ararunprasad/following{/other_user}","gists_url":"https://api.github.com/users/ararunprasad/gists{/gist_id}","starred_url":"https://api.github.com/users/ararunprasad/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ararunprasad/subscriptions","organizations_url":"https://api.github.com/users/ararunprasad/orgs","repos_url":"https://api.github.com/users/ararunprasad/repos","events_url":"https://api.github.com/users/ararunprasad/events{/privacy}","received_events_url":"https://api.github.com/users/ararunprasad/received_events","type":"User","site_admin":false},"created_at":"2018-03-31T13:18:53Z","updated_at":"2018-03-31T13:18:53Z","author_association":"CONTRIBUTOR","body":"I think we avoid the merge commit using Git [fast forward merge](https://confluence.atlassian.com/bitbucket/git-fast-forwards-and-branch-management-329977726.html),  \r\n\r\nIn our case, there are 3 repos involved,\r\n\r\n1. jfx-dev:rt(hg)\r\n2. git-hg-intermediate (git + hg)\r\n3. github:rt(git)\r\n\r\nWe always do only way merge from repo#2 to repo#3, since repo#3 has some extra commits, so Git can't do fast forward the merge. That's why we see the merge commit. Once we merge repo#3 to repo#2, extra commits will be merged with repo#2 and all future commits can be forwarded by Git."}}
{"actor":{"display_login":"ararunprasad"}}