Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitHub pull request review #702

Merged
merged 22 commits into from Jan 25, 2017

Conversation

Antondomashnev
Copy link
Member

@Antondomashnev Antondomashnev commented Jan 22, 2017

Hi, there this PR addresses an issue I opened a while ago #684.
The status is kinda work in progress, but there is already functionality that can be potentially used.

The changes in this PR:

  • new module GitHubSource to combine the only GitHub related features;
  • new class Review under the GitHubSource module, which represents the pull request review object;
  • extension to octokit which I think will be used until the API is not final and then I will create a PR to octokit itself with extension for pr reviews;

Here is an example of how it looks like in Dangerfile:

github.review.start
github.review.fail("I can fail your PR in a moment")
github.review.warn("I'm warning yo")
github.review.message("100 message")
github.review.submit

You can check how it looks in a PR here

The open points I want to discuss:

  1. The overall design approach
  2. Do we need the summary message in review? My intention to create it was to write something if the PR is well done and danger approves it without any comment.
  3. Do you think it could be used without inline comments as a first step or you prefer the feature with inline comments?

P.S. the changelog is not modified yet and I haven't cleaned the commit history yet.

Copy link
Member

@orta orta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks 👍 to me. I'm fine without doing line/file comments at first, as long as we document it as such

end

# @orta @JuanitoFatas to be discussed whether we should submit review with
# the same status as already submitted by danger before
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on an PR update? I think that's 👍

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 5730d68

post "#{Repository.path repo}/pulls/#{pull_request_number}/reviews/#{review_id}/events", options.merge(review)
end
end
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice one

# @!group PR Review
# Current PR Review object.
# @return [GitHubReview]
#
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will need considerable documentation before we ship ( as this is what an end user would see on the website ) - I'm happy to do this once you're ready though 👍

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, do you think we should provide an example here or what are your thoughts? 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure thing, something like this

# @!group PR Review
#
# In Beta. Provides access to creating a GitHub Review instead of a typical GitHub comment.
#
# To use you announce the start of your review, and the end via the `start` and `submit` functions,
# for example:
#
# ```
#   github.review.start
#   github.review.fail("Please add a CHANGELOG entry") if has_no_changelog
#   github.review.warn("Highway to the Danger Zone") if pr_includes_word_danger
#   github.review.message("You might want to read #{url}") if may_require_docs
#   github.review.submit
# ```
#
# @return [GitHubReview]

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

People don't see the inline documentation for the review object, so it needs to be attached to this DSL attribute to end up on the reference - http://danger.systems/reference.html

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@orta looks cool 👍
The small feedback:

  1. @return [GitHubReview] -> @return [GitHubSource::Review] or we can just leave Review.
  2. Should we mention github.review.markdown(...) ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@return [GitHubReview] -> @return [GitHubSource::Review] or we can just leave Review.

IMO @return Review is fine, maybe even @return ReviewDSL as these docs are for end-users who don't care about our internal semantics

Should we mention github.review.markdown(...) ?

Yep :D - please make it a real-ish example like the ones above

class Review
include Danger::Helpers::CommentsHelper

# @see https://developer.github.com/v3/pulls/reviews/ for all possbile events
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

possbile

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 5730d68

@orta
Copy link
Member

orta commented Jan 22, 2017

The overall design approach

This feels 👍 to me

Do we need the summary message in review? My intention to create it was to write something if the PR is well done and danger approves it without any comment.

I think approval without comment is perfectly fine IMO, if this does't feel right, we can change that at a later date. Note you should check if that's possible before making the assumption it is possible.

Do you think it could be used without inline comments as a first step or you prefer the feature with inline comments?

Fine by me

@Antondomashnev
Copy link
Member Author

Antondomashnev commented Jan 23, 2017

I think approval without comment is perfectly fine IMO, if this doesn't feel right, we can change that at a later date. Note you should check if that's possible before making the assumption it is possible.

Currently, it looks like this for example:

But yeah, maybe less "spammy" messages in PR - better 😄

@orta
Copy link
Member

orta commented Jan 23, 2017

Yeah, if a review can be posted with 0 comments, I think it's worth adding instead of the redundant one there

@orta
Copy link
Member

orta commented Jan 23, 2017

Yeah, like this one ^

@JuanitoFatas
Copy link
Contributor

Rubocop is not happy 👮 Other than offenses, 👍 Great work!

@Antondomashnev
Copy link
Member Author

Antondomashnev commented Jan 24, 2017

@JuanitoFatas yep, I've noticed it, but I'm a bit confused now why it's green on my local machine with the same command.
Do you have any idea why it could happen?

I've also created a test #704 with up to date master and it fails with rubocop as well, really weird.

@orta
Copy link
Member

orta commented Jan 24, 2017

Do you have any idea why it could happen?

I've always wondered if Rubocop actively ignores the fact that you're using bundler with it

@Antondomashnev
Copy link
Member Author

Antondomashnev commented Jan 25, 2017

Aha, that could be the case rubocop/rubocop#3968
I wanna try to downgrade rubocop to 0.46 and see what happens.

@DangerCI
Copy link

DangerCI commented Jan 25, 2017

1 Warning
⚠️ .gemspec modified

Generated by 🚫 danger

@Antondomashnev Antondomashnev changed the title GitHub pull request review [WIP] GitHub pull request review Jan 25, 2017
@Antondomashnev
Copy link
Member Author

Antondomashnev commented Jan 25, 2017

Yes the latest rubocop release of 0.47.1 was the issue.

@orta
Copy link
Member

orta commented Jan 25, 2017

Alright - this looks good to me, lets get this shipped.

@orta orta merged commit 98cd768 into danger:master Jan 25, 2017
@Antondomashnev Antondomashnev deleted the antondomashnev/github_review branch January 25, 2017 22:20
@orta
Copy link
Member

orta commented Jan 25, 2017

Awesome - shipped as 4.1.0

@Antondomashnev
Copy link
Member Author

@orta thanks, could you explain why the continuous-integration/appveyor/pr is red? Never worked with it 😄

@orta
Copy link
Member

orta commented Jan 25, 2017

It runs our CI on windows, it's been having issues on all my OSS - might be capacity issues

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants