issue_comments
3 rows where author_association = "MEMBER", issue = 297794911 and user = 6815844 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: reactions, created_at (date), updated_at (date)
issue 1
- Remove flake8 from travis · 3 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
369112822 | https://github.com/pydata/xarray/pull/1919#issuecomment-369112822 | https://api.github.com/repos/pydata/xarray/issues/1919 | MDEyOklzc3VlQ29tbWVudDM2OTExMjgyMg== | fujiisoup 6815844 | 2018-02-28T03:50:57Z | 2018-02-28T03:50:57Z | MEMBER | Thanks for the information. I do not have much experience about HoundCI but if it works well, it could be an alternative of stickler.
But why is travis so special? HoundCI reports any flake8 violation not only as comments but also in All checks have passed part of PR, as travis does. I think that maintainers can check any flake8 violation just from HoundCI, before merging. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Remove flake8 from travis 297794911 | |
369108264 | https://github.com/pydata/xarray/pull/1919#issuecomment-369108264 | https://api.github.com/repos/pydata/xarray/issues/1919 | MDEyOklzc3VlQ29tbWVudDM2OTEwODI2NA== | fujiisoup 6815844 | 2018-02-28T03:19:42Z | 2018-02-28T03:19:42Z | MEMBER | @Zac-HD, I don't mean to drop CI-based flake8 checking. We are trying to move stickler-ci, which is a CI specific for flake8 check. I thought if stickler works fine, travis could concentrate on testing, but stickler does not behave as what I have expected. I agree that it is not a good idea to remove flake8 check from travis at this moment. I think that in the early stage of the development it would be nicer if we could easily distinguish between testing failure and style inconsistency, but travis just says succeeded or not. (it is possible to find it if we look deep inside the travis's log, but it requires some burden). Do you have any idea to realize more explicit failure reporting? |
{ "total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Remove flake8 from travis 297794911 | |
366488172 | https://github.com/pydata/xarray/pull/1919#issuecomment-366488172 | https://api.github.com/repos/pydata/xarray/issues/1919 | MDEyOklzc3VlQ29tbWVudDM2NjQ4ODE3Mg== | fujiisoup 6815844 | 2018-02-18T02:42:27Z | 2018-02-18T02:42:27Z | MEMBER | OK. Let's wait a little more. It looks the rules are a little bit difference between flake8 in travis and stickler-ci. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Remove flake8 from travis 297794911 |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE [issue_comments] ( [html_url] TEXT, [issue_url] TEXT, [id] INTEGER PRIMARY KEY, [node_id] TEXT, [user] INTEGER REFERENCES [users]([id]), [created_at] TEXT, [updated_at] TEXT, [author_association] TEXT, [body] TEXT, [reactions] TEXT, [performed_via_github_app] TEXT, [issue] INTEGER REFERENCES [issues]([id]) ); CREATE INDEX [idx_issue_comments_issue] ON [issue_comments] ([issue]); CREATE INDEX [idx_issue_comments_user] ON [issue_comments] ([user]);
user 1