beeware / beefore Goto Github PK

Hi there, long time no see!

a college just send the link for this project. Looks great. So great in fact, that me and a bunch of friends have been working on something similar. Maybe we can join forces?

I did present it on DjangoConEU2018, but I think @freakboy3742 was making too many bee jokes to notice what I was talking about ;)

Anyhow, there are some differences on how we implemented this concept. We did use AWS lambda to run all linters. We also used GitHubs new checks API. This allows users to stay on GitHub and receive feedback immediately.

Maybe it doesn't make sense to combine those to project after all, in any case we made it open source. Feel free to borrow code if you need it :)

https://lambdalint.github.io
https://github.com/lambdalint

Best
-Joe

Are we using (or planing to use) some code formatter (yapf/autopep8) to format code, check code on PRs?

I wrote https://github.com/continuumio/ciocheck to do this on some of my projects, so that if CI fails if the code formatter changed the code in anyway.

We need a a Beefore task that will do a spell check of any changes to the documentation directory.

I was wondering if there is the possibility to add to the check something like

pip list --outdated

and fail the check if new packages have been updated. Maybe we need some kind of flexibility, so we want to pass a certain amount of packages with versions that could be skipped?

Just a thoughts.

Access tokens Are a necessity for users who have Two-Factor-Authentication enabled.
They should be Available to be used instead of a password, perhaps taken from an environment variable automatically

Sometimes, some changes sneak into master that don't pass the checks.

If afterwards there a pull request is made in a completely different section of the code - the same checks will fail! with no fault of the contributor.

A possible fix for this is to only run checks on the lines that are changed by the PR.

While still in beta, GitHub has "suggested changes"

https://help.github.com/articles/incorporating-feedback-in-your-pull-request/#applying-a-suggested-change

The format of which is a codeblock with the name 'sugguestion' ('```suggestion')

I'm not entirely sure if any of our current linters support autofixing, but for those that do, this might be useful.

It would be really handy for beefore to be able to be run as a pre-push git hook.

In order to make that happen, beefore should take an option like --local-sha that skips trying to login to github and runs the checks on the local diff.

Beefore currently has some implicit assumptions that it's running on a PR that is active, and on GitHub. While this is an important use case, it's also important that we can run against a local git checkout.

On recent VOC PRs, when there is a javacheckstyle issue, the add_comment bit fails and stops the full list of checkstyle issues from being returned, so you can only see the first error.

• beeware/voc#706
• output: https://beekeeper.herokuapp.com/projects/pybee/voc/change/56fc9e98-c8c3-4aad-966a-c54d29306aac/build/85978281-d18b-4cb2-a85f-e1fa0fb2fed2/task/beefore:javacheckstyle

The readme says docs are at https://beefore.readthedocs.io/
but today I got a creative asciiart instead:

Read the Docs

Log in


    \          SORRY            /
     \                         /
      \    This page does     /
       ]   not exist yet.    [    ,'|
       ]                     [   /  |
       ]___               ___[ ,'   |
       ]  ]\             /[  [ |:   |
       ]  ] \           / [  [ |:   |
       ]  ]  ]         [  [  [ |:   |
       ]  ]  ]__     __[  [  [ |:   |
       ]  ]  ] ]\ _ /[ [  [  [ |:   |
       ]  ]  ] ] (#) [ [  [  [ :===='
       ]  ]  ]_].nHn.[_[  [  [
       ]  ]  ]  HHHHH. [  [  [
       ]  ] /   `HH("N  \ [  [
       ]__]/     HHH  "  \[__[
       ]         NNN         [
       ]         N/"         [
       ]         N H         [
      /          N            \
     /           q,            \
    /                           \

Copyright 2010 - 2016. Created by Eric Holscher, Charles Leifer, and Bobby Grace for the 2010 Django Dash.
GitHub | Docs. Made by humans. Funded by readers like you.

//Update;
Readthedocs refers to several required steps;
1.Account on Readthedocs to link to the code here on github.
https://read-the-docs.readthedocs.io/en/latest/getting_started.html#import-docs
2.Folder /docs to contain the Sphinx website, constructed via make after pip install sphinx.
The first tutorial is here https://youtu.be/oJsUvBQyHBs?t=446

Part [1] the admin here would need to do.
Part [2] I could at least make a hello world type of doc, if that is agreeable.

Per beeware/voc#640, it seems that checkstyle errors may not be picked up correctly by javacheckstyle.py due to the regex used to parse the checkstyle output.

I was just running ant checkstyle locally and I saw two slight variants of error outputs, the latter with no column number:

[checkstyle] [ERROR] /Users/cflee/Projects/voc-dev/voc/python/common/org/python/types/Bytes.java:1237:18: '{' is not preceded with whitespace. [WhitespaceAround]
[checkstyle] [ERROR] /Users/cflee/Projects/voc-dev/voc/python/common/org/python/types/Str.java:1: File length is 2,374 lines (max allowed is 2,000). [FileLength]

Feeding these lines (separately) into https://pythex.org with LINT_OUTPUT, the line number captured is 18 for the former instead of 1237. This seems like it will cause the checkstyle error to get ignored, as line 18 didn't change, so it doesn't exist in the diff.

The current LINT_OUTPUT captures the line number 1 correctly for the latter, so I'm just including it to make sure both output cases are handled in the fix. But it is less important, since even if parsed correctly, any non-line-1 change that triggers a file-level error (and listed as line 1 by checkstyle) will get ignored by the same heuristic.

The Quickstart section in the README is blank.

The code reviews in This pull request all point to the wrong lines.

As per #2, the code isn't stable enough for wider publication. Let's call this the parent issue for tracking and split out some sub-issues as required.

Send an email to the person who made the PR telling that the build succeeded or failed. This way people can go do other stuff and just wait for the result in the email instead of refreshing the PR page

We may be able to use /PyCQA/flake8-import-order