teobiton / issue-tracking Goto Github PK

Rather than using crate StructOpt for arguments manaement, which forces us to use a lot of decorators, we could use the built-in Command/App crates for the application

Example: bat(1) on GitHub

To enhance the application, data coming from the json file could be filtered based on the following criterias:

• label: the issue is labelled with a particular label,
• from-date: the issue was updated after the specified date,
• until-date: the issue was updated before the specified date,
• state: the issue is opened or closed

This could be done using structs and traits, based on the design pattern found here https://doc.rust-lang.org/stable/book/ch17-03-oo-design-patterns.html

The issue-tracking project could take advantage of some linting checks, cargo clippy could help with this.

So far, the request from GitHub API only gives us back 30 issues. All pages should be fetched until we have all issues from a repository.

By parsing the serialized data, all labels used in a repository could be displayed to the user so that they could either check the spelling or see what is available for a certain repository.

CI should check if cargo fmt was run on the project prior to a push to the main branch.

While using the crate, two bugs where found:

• State input has the wrong default value: should be "any", currently is ""
• When building date filters, end_active boolean is true by default because the wrong input is checked (from_date instead of until_date)

Coverage of these two bugs by test should be added as well.

There are two cases for usage of this project:

• In an offline environment, users might pass as input a json file that was retrieved via an other method.
• In an online environment, users might retrieve the json file directly from the GitHub API.

Either way, in case of an offline use, the dependencies should be installed in a folder dependencies/ so that people are able to use the tool in both cases.

The default values displayed in the help message do not represent the actual values that are assigned in the end, for the output and for the label. This should be fixed.

Based on #8, it could be relevant to have a build.rs file that can install the application either for online use or offline use based on different features.

For such features, we could have optional dependencies that only build in online use (see https://doc.rust-lang.org/cargo/reference/features.html).

Check the available crates for profiling and see how the code could be optimized.

The Clippy check (style lint) is failing in build fail. This must be fixed.

So far, we're leaving process on error "manually", by printing in stderr and calling process exit with code error 1.
There might be a better way to do it using either Err() or ExitFailure crates, or something else.

Currently, we are expecting JSON files as required arguments for issue-parser.

To make it more user-friendly, a new flag could be introduced so that users could pass a link to a GitHub repository instead of a JSON file. With this flag, the JSON file could be fetched directly from GitHub API, but this requires an internet access for usage.

If this is implemented, we should have a separate testlist for tests of this feature since some of them will require an internet access.

An example could be: -u or --url.