issue_comments

Table actions

3 rows where author_association = "MEMBER", issue = 297794911 and user = 6815844 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: reactions, created_at (date), updated_at (date)

user 1

  • fujiisoup · 3 ✖

issue 1

  • Remove flake8 from travis · 3 ✖

author_association 1

  • MEMBER · 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.

they still check flake8 in Travis to ensure everything is fixed before merging.

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

CSV options: 

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]);