kowainik / hintman Goto Github PK

Function with roughly with the following type (of course, we should use data types instead of tuples):

suggestNoTrailingSpaces :: (FilePath, Text) -> Maybe (FilePath, LineNumber, Text)

which generates suggestion comment for github with the same line but without trailing spaces if the line has one.

Module: Hintman.Suggest

And then implement function that takes list of files with lines and diffs and traverses all lines and generate all hints.

GitHub tutorial briefly mentions to use Heroku.

In HLint the Idea stores the SrcLoc of the corresponding code of the hint, so we should make sure that we make the suggestion only to the corresponding part and leave the rest as it is.

curl command:

curl -i -H "Accept: application/vnd.github.v3.diff" https://api.github.com/repos/gr2m/sandbox/pulls/7

And here is the library we're going to use for parsing diffs:

• http://hackage.haskell.org/package/diff-parse

This is a final issue. Basically, wire up everything together. This is a tricky issue, we need to figure out how to use GitHub API to submit comments for corresponding lines....

So later we can enable or disable logging in our application via this flag.

Basically, just implement simple endpoint that will print some info about open PRs for the repo. We're going to use the following libraries:

• https://github.com/onrock-eng/github-webhooks
• https://github.com/tsani/servant-github-webhook

And here is the simple example of using servant-github-webhook:

• https://github.com/onrock-eng/github-webhooks/tree/master/examples/servant-simple#readme

Currently we print all request to the terminal. But we need to implement verification. See these lines from boilerplate app:

• https://github.com/github/platform-samples/blob/8658ba6836613ca2510513284967486bb3f3f516/api/ruby/building-your-first-github-app/server.rb#L115-L118

This might be a useful thing to add to the context along with whether or not to log things.

Can be started after #38

Using hlint as library and data types from there.

Some repositories may have their own .hlint.yaml files. It would be nice to support them.

There's Context in servant and having Context for CLI makes this a little bit awkward...

Some may want to see all hints and warnings, some may not.

We should filter on this data type then: Severity

I don't know why it's needed but Ruby example has it.

Can be started after #38

ReaderT Env IO representation is more efficient.

Documentation for building APP:

• https://developer.github.com/apps/building-your-first-github-app/#start-a-new-smee-channel

I would like to have instructions how to configure environment before running application. Better in a form of shell script. So in terminal everyone can just:

$ ./setup-app-env.sh
$ cabal new-exec hintman  # or `stack exec hintman`

If something is required to do manually, this should be specified in the README.md file.

• servant
• optparse-applicative
• jwt
• hedgehog
• relude
• tomland

We now have multiple checks. And it's probably a good idea to have a config for our tool anyways. So we can create Config data type where we can store all checks and allow users to have .hintman.toml in their repos to disable or enable checks.

Should go in Hintman.Config module.

According to our latest innovations

Currently hintman doesn't start when config file is not present. I think it's better to use default configuration in that case and print that it will be used.

• Rename HintmanAppM to just App
• Rename HintmanEnv to just Env
• Move App to Hintman.App.Monad
• Move Env to Hintman.App.Env

So everyone can test GitHub application. Here is the application:

• https://github.com/apps/hint-man

It's created under my account but probably we need to create one under Kowainik. And also we probably need to create one more GitHub application for testing...

Also, probably we need to create an empty repository for testing. But this repository can be useful for both hintman and hit.

1. Delete all repos on the deletion
2. Throw errors properly

We need to cache installation Id for each pair of owner and repo. And we also should keep tokens for 1 hour and reuse them without renewal.

Looks like InstallationToken is shared for all repositories of the same user. So we can simplify mapping and make code more correct.

There's problem that requestBody is deprecated and getBodyChunks consumes request body making it not accessible to further. This problem should be solved after GSoC project for servant-auth when this library becomes extensible.

Let's not remove authentication completely. Just comment all code that verifies signatures (and remove cryptonite from dependencies) and just log incoming request in there.

Blocked by #10

Currently just do putTextLn. Later we will use co-log for logging 😎

When PR is open, hintman should create some dummy comment on the diff. The API is tricky but dummy comment should be easy to create:

• https://developer.github.com/v3/pulls/comments/#create-a-comment

Here is the documentation:

• https://developer.github.com/webhooks/

So, since we now have multiple hints, it actually makes sense to think about aggregating structure. So the overal structure is the following:

1. Have the following top-level function

suggest :: [(FilePath, Text)] -> [Suggestion]

It takes path to file and content of this file and performs joinSuggestions . concatMap suggestSingle where
2. The function suggestSingle will split incoming text over lines and then run all our suggestions either on every line or on the whole content
3. We might have multiple suggestions for single line so we need to aggregate suggestions. For example, if we have trailing line \n we need to perform the only suggestion that removes this line, not two suggestions. So should Suggestion type be Monoid 🤔 Any ideas are appreciated!

cc @willbasky @sphaso @vrom911

We need to verify that requests are from GitHub. But for now we can just print all incoming requests and see what they contain.

Basically, implement simple API with servant that returns number 42 on some predefined URL like

/api/the-answer

We should use generic servant for that.

The module name can be Hintman.Server.

Blocked by #39

This function should do the following:

1. Get the InstallationToken from the context
2. Renew it if necessary
3. Do this in thread-safe way

When the PR is open, we need to get all files, their content and run hlint over them. We're going to use hlint as a library.

Blocked by #9

After #9 is implemented we should introduce our custom monad that stores Config in ReaderT context and use the config.

This could even be couple of unit tests with hspec

We can submit suggestions only to changed lines. We get this information from diff-parse. So we need to filter all hints according to diff.

I'm not sure how it's going to work. But if we deploy GitHub app manually as a runnable server, we have to figure out how to persist installation ids to be able to restart server smoothly. If we store them only in memory we lose all information and can't run hintman over repos where it's already installed.

Similar to #3 but should check that commit introduces trailing newlines.

Might be a bit hard but for every file we should check that diff lines at the end of this file doesn't introduce trailing newlines.

Let's do this in separate module Hintman.Suggest.TrailingNewline (probably later will be merged with what @willbasky is doing).

It's possible to specify only some repositories via GitHub API to be accessible by Hintman. So there are two options:

1. If events are not sent from disabled repos, we don't need to do anything. Just need to verify it.
2. If events from disabled repos are sent then we need to store this information about all enabled repos inside the environment to not review PRs on disabled repos.

We need to think about how to generate random data with trailing spaces, implement verification function for this data and then check against the function implemented in #3

Just check how it's done in summoner