groovecoder / discord Goto Github PK

File: https://github.com/mdn/YouShouldUse/blob/50b2d44c4cc1eb042e7fffa406446f2230b1f204/module.js#L17

After connecting the main YSU to my test repo, I saw this:

http://content.screencast.com/users/davidwalsh83/folders/Jing/media/052c27b5-cc74-4d09-a4e0-e35236172d05/00000293.png

"8 comments...."

Only one comment, however, was added:

darkwing/compat-tables@3ccdf94

Right now gulp complains about a couple of style issues with the code (an if without braces and a missing semicolon).

Since I need to get familiar with the code base (and everybody wants to appease linters :P) I'm thinking about tackling this.

As per the conversation in #15. Likely would best be done with a database. So what db do we use?

We're using doiuse 0.3.3 released May 2. The latest is 1.0.2 release today.

#33 was a good start, and the logging in renderComment is good too. We should add logging of commits checked and .css files found too. So we know the hook is processing payloads even if it doesn't find any issues.

Keep track of how many repositories are sending at least one pull request payload to Discord per week.

https://youshoulduse.herokuapp.com/ should include a link and a big notice like, "YouShouldUse is under heavy development. Please file any and all issues you find as you try it out."

Current specification

Compatibility comments should be made under the MDN brand. It should look like MDN itself added the comment.

Allow users to add browsers to check and features to ignore in a .doiuse config file.

It's be nice not to moderate the tone of the comments when a user is using good progressive enhancement techniques. For example: a box-radius that isn't supported is probably not going to be a problem but lack of support for display: flex could be pretty catastrophic.

If a pull request is submitted, then another commit pushed to that branch (thus updating the PR), the entire PR is then reevaluated and commit comments duplicated.

File: https://github.com/mdn/YouShouldUse/blob/e44851138fe34fa4826501f7647436d81d78328f/module.js#L15

There may be times when a stylesheet cannot be tested: for example, if Stylus cannot be compiled. When this happens, we should post a comment to the pull request discussion (not a line comment) mentioning that the stylesheet could not be tested.

To quickly get more feedback from users, we should link them straight to our issue tracker from the comments on their commits.

With worker.js, the minimum cost to test the app is now $32, since worker needs it's own dynamo. We should point this out in the README/testing documentation, since this will require adding a credit card.

Steps to reproduce:

• I submitted a PR with one commit with valid CSS (so there would be no errors)
• I added a commit which did include some invalid CSS properties

https://github.com/darkwing/YouShouldUseTest/pull/6/files

Comments were automatically added upon pushing the second commit (yay!) but they appear to be added to wrong lines.

https://learnboost.github.io/stylus/

We're getting to the point where we want tests on the repo so we can test against certain payloads without having to make real commits on GitHub.

File: https://github.com/mdn/discord/blob/fb8f4f25a62c625af2a13a437c73ee962a990e08/hook.js#L40

We enabled the hook on the kuma code-base, and merged mdn/kuma@d575949 into master.

They payload delivered successfully to the hook, but the heroku logs show ...

2015-06-10T19:46:07.348792+00:00 heroku[router]: at=info method=POST path="/hook" host=youshoulduse.herokuapp.com request_id=5767898a-3792-4337-80cb-3d52c0539b24 fwd="192.30.252.45" dyno=web.1 connect=1ms service=42ms status=200 bytes=211
2015-06-10T19:46:07.332623+00:00 app[web.1]: Wed, 10 Jun 2015 19:46:07 GMT express deprecated res.send(status, body): Use res.status(status).send(body) instead at module.js:13:9
2015-06-10T19:46:07.342132+00:00 app[web.1]: Repo: mozilla/kuma
2015-06-10T19:46:08.603048+00:00 app[web.1]:     return sourceMap.sections != null
2015-06-10T19:46:08.603050+00:00 app[web.1]:                     ^
2015-06-10T19:46:08.603052+00:00 app[web.1]: TypeError: Cannot read property 'sections' of undefined
2015-06-10T19:46:08.603042+00:00 app[web.1]: /app/node_modules/source-map/lib/source-map/source-map-consumer.js:23
2015-06-10T19:46:08.603055+00:00 app[web.1]:     at /app/sourceParse.js:22:26
2015-06-10T19:46:08.603057+00:00 app[web.1]:     at Renderer.render (/app/node_modules/stylus/lib/renderer.js:107:12)
2015-06-10T19:46:08.603054+00:00 app[web.1]:     at new SourceMapConsumer (/app/node_modules/source-map/lib/source-map/source-map-consumer.js:23:21)
2015-06-10T19:46:08.603061+00:00 app[web.1]:     at Request.emit (events.js:110:17)
2015-06-10T19:46:08.603060+00:00 app[web.1]:     at Request.self.callback (/app/node_modules/request/request.js:354:22)
2015-06-10T19:46:08.603058+00:00 app[web.1]:     at Request._callback (/app/sourceParse.js:21:17)
2015-06-10T19:46:08.603063+00:00 app[web.1]:     at Request.<anonymous> (/app/node_modules/request/request.js:1207:14)
2015-06-10T19:46:08.603064+00:00 app[web.1]:     at Request.emit (events.js:129:20)
2015-06-10T19:46:08.603067+00:00 app[web.1]:     at IncomingMessage.emit (events.js:129:20)
2015-06-10T19:46:08.603066+00:00 app[web.1]:     at IncomingMessage.<anonymous> (/app/node_modules/request/request.js:1153:12)

When using OAUTH authentication, we are limited to 5,000 API calls per hour. We need to handle the case where the limit is reached.

It appears that beautify is either not been used recently, or has settings that seem to differ based on the system used.

STR:

1. Create a PR with the hook enabled
2. Close the PR
3. Re-open the PR

Expected results:
Only opening a PR should add a comment

Actual results:
Closing the PR created another batch of line-by-line comments

Example:
groovecoder/discord-test#1

Current specification

When someone submits a pull request to a repository that has YouShouldUse installed, it should go through and add compatibility comments to the lines of code modified in the pull request.

Quoting @darkwing:

Here's what I've done that is not yet working:

1. Go to my GitHub settings, created a Personal Access Token with the permissions: admin:org_hook, admin:repo_hook, gist, repo, user
2. Added token to my env: export OAUTH_TOKEN=XXXXXX
3. Added a commit to my test repo's master branch, pushed to GitHub
4. Checked out the commit display on GitHub...no comments :(

The Personal Access Tokens page also mentions the token has never been used.

http://lesscss.org/

Improve messaging and formatting of comments. Depends on #13.

Create a landing page at / with instructions to install the webhook to a GitHub repository.

At present, when a commit's files are analyzed by YSU, the entire file is analyzed instead of simply the file's diff data. This is problematic because the repo page shows one comment count for the commit:

https://camo.githubusercontent.com/97b8401bdc0161d88b275b74b952f64a5913bbea/687474703a2f2f636f6e74656e742e73637265656e636173742e636f6d2f75736572732f646176696477616c736838332f666f6c646572732f4a696e672f6d656469612f35346563636539632d313336322d343063622d383137322d3464363837383334316665612f30303030303239382e706e67

...instead of just the number of comments that the use will be shown when the browse the commit itself.

Today, while setting up the environment, I noticed the instructions about the creation of a personal access token inside the CONTRIBUTING.md file are unclear. It seems one should add the following permissions:

• admin:repo_hook
• admin:org_hook

Or so I've been instructed by @darkwing .

Is this correct? If yes, I'll amend the file to include the information.

When a person sets up the webhook for the first time, test all files in the repository.

If a repository has an empty .doiuse file, an empty configuration is used. The stylesheets of that repository are not tested against any browsers. This is "by design", but in hindsight, it's a pretty dumb design. I can't imagine why anyone would expect this behavior.

We should treat an empty .doiuse file like a non-existent .doiuse file and fall back to the default configuration.

New Relic provides some great preformance and error monitoring. It's very easy to add to Heroku apps.

https://devcenter.heroku.com/articles/newrelic
https://devcenter.heroku.com/articles/newrelic#node-js-installation-and-configuration

Instead of reporting all issues in one comment at the bottom of the file, report issues in-place as line comments. Do not add line comments for issues related to lines that did not change it that commit.

http://sass-lang.com/

When a user submits comments too quickly, the account is temporarily prevented from adding more. GitHub prints a message explaining this if you try to manually add a comment after running Discord. This restriction explains why Discord does not comment on all incompatibilities.

I was able to make Discord comment on all incompatibilities by pausing for a random amount of time between each comment but that's just a proof-of-concept. We'll need a much different implementation for production. Some kind of queue would be great, but I can't find a node queue that can be configured to pause between tasks.