volvo-cars / reviewcheck Goto Github PK

This list can be updated with things we need to do/fix in the release PR:

• Include the --version flag in the changelog

If the config cannot be parsed, doesn't contain all necessary values, or there is something wrong with it, an exception should be raised.

All available colors should be used. The color should be deterministic so that each MR has a color that doesn't change between runs.

Currently, Reviewcheck supports only GitLab Merge Requests. It should be possible to implement support for GitHub Pull Requests, as well as Gerrit Changes.

This is an umbrella issue for the investigation part, expected outcome is a report explaining what work should be expected for either system, preferably posted as a comment in this issue. If/when investigation is completed, issues for the actual implementations should be created and this issue closed.

Background

GraphQL is likely more efficient than REST. It should be possible to download the information for all merge requests at once this way.

What to do

Replace usage of the GitLab REST API with the GraphQL API.

When looping reviewcheck with the -r flag, it would be good if the screen could be cleared for real, rather than 30 newlines added.

This makes it simpler to add projects. Should probably revisit the parsing if we do this, as multiple space-separated URLs doesn't seem very nice. One suggestion is to continuously read until the user submits the empty string.

Things like column width, the formatter we use, doc comment style, and everything else.

Username needs to be uppercase because that's how GitLab shows it. We used to change the name so that it was all caps, but this functionality disappeared at some point. Fix.

Currently, we read the config file into a raw dictionary. This leads to needing to explicitly extract fields by subscripting, in order to be ergonomic. Example: user = config["user"]. This isn't very nice, instead we should create fields on the Config class. This may involve restructuring the current pattern a bit, as the Config class today is mainly a namespace for setup and retrieval of the config file. The get_configuration method should probably be removed, in favor of just accessing the (new) fields directly, for instance.

By researching the GitLab API, we should be able to improve performance when fetching data – especially when getting all merge requests.

If any more suggestions for performance improvements arise, please leave them here as a comment.

Send a desktop notification when there is something new to respond to compared to the last run. This depends on us first making it possible to store the state.

The GitLab API provides an URL to the profile picture of a commenting user. We could download this to a temporary directory and give information about it to notify send so that the user can more easily see who commented.

We need unit tests, sooner rather than later. This issue is deliberately vague in its expected outcome, but once there are a few tests this can be considered done.

We look for the jira ticket number in the MR descriptions. Currently, the format has to be

JIRA: Ticket-name

We should also catch e.g:

Jira: Ticket-name

If the user has replied to everything, reward the user by printing "Good job" or similar. Maybe choose from a list of praises. Or tell them that they need to get involved in more reviews.

I usually close the app when running in a loop by doing ctrl + c. This raises an exception (something like "KeyBoadInterruptException"). Catch this exception and close cleanly.

When GitLab is down, one may see the following:

adapters.py", line 501, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))

It seems that this should be caught at requests.get(). Maybe it should be treated differently depending on the error code.

Every discussion should show the date.

Reviewcheck needs to be able to fetch the latest data and run in the background so that users see when there are new comments to respond to, without manually having ti re-run Reviewcheck.

You should be able to set project ids in the config. Possibly with a link to the gitlab page, but in that case it should work for any gitlab instance.

It can be difficult to know what to submit. What's my GitLab URL? What are my project ID:s (this will be improved in #41 also)?

We should probably have a heading above each entry, instead of just a prompt on the same line. The heading should explain what it is, what it is used for, and where to find it.

Be especially considerate regarding the secret token. Explain thoroughly how to create one, and what permissions are needed. A URL would probably be nice here.

This is better practice in general, and would allow to use different kinds of UI – e.g. one with rich (current), one machine-readable, one big JSON-file, and so on.

The project should be built in the workflow.

The code base, as it is currently, is still mainly one file. We should refactor into different files and classes/functions to make it more robust and maintainable.

@olof-j suggests using dependabot to update dependencies: #86 (review)

Investigate this.

We should publish the releases to GitHub in addition to Artifactory. Do this in the deploy stage of the deploy workflow.

Should probably investigate if this is secure as well, but it should be ok.

The info is in the README but should also be visible to users when they need it.

The info box should show the branch name so that it is easy to check out if you want to test the MR locally

Currently we're getting the version from more than one place which is error prone. When setting the __version__ variable internally, we should read the pyproject file with some toml parser (I think there is one in the dependencies) and get it from there, rather than hardcoding it again.

There's already an issue for making the output/UI scriptable, this is more about figuring out what needs to be done to make Reviewcheck ergonomic to use in a shell script. Things like return codes, silent operations, filtering by "check type" (author, pinged, etc.) should be considered. A comment on this issue explaining what should be done is enough here, as well as creating new issues.

One (maybe goofy) idea is that the return code of the program can the same as the amount of open threads. Perhaps not as default, but as a flag?