teobiton / issue-tracking Goto Github PK

Command-line tool to track GitHub repositories issues and export them to csv.

License: Apache License 2.0

Rust 100.00%

issue-tracking's Introduction

Issue tracking

This command-line tool can be used to parse JSON files containg data from a GitHub repository issues and export it to csv. The purpose is to retrieve the data easily, pre-process it with the tool and then only keep valuable information. The information retrieved consists of an issue's ID, its creation date, last update date, state and title.

Example

Command:

$ issue-tracking teobiton/issue-tracking --get --output=example.csv --state=open

Output in example.csv:

ID,Created at,Last update,State,Comment
9,2023-06-01,2023-06-01,open,Create `build.rs` for installation
1,2023-05-15,2023-05-15,open,Move from StructOpt to App

Usage

The tool requires a JSON file containing GitHub issues, or a valid GitHub repository name. A valid JSON file can be retrieved either with a plugin from a browser or by accessing GitHub API for a repository with curl. This is the help message of the application:

issue-tracking 1.0.0
GitHub issues parser and exporter from JSON to csv

USAGE:
    issue-tracking [FLAGS] [OPTIONS] <json>

FLAGS:
    -g, --get             GET the JSON file from GitHub API.
    -h, --help            Prints help information
        --print-labels    Print all available labels in the repository.
    -V, --version         Prints version information

OPTIONS:
        --end-date <end-date>        Only consider issues updated before this date. Format: YYYY-MM-DD [default:
                                     (newest)]
    -l, --label <label>              Filter the issues based on a label. [default: (all)]
    -o, --output <output>            Specify a file to store the csv. [default: out.csv]
        --start-date <start-date>    Only consider issues updated after this date. Format: YYYY-MM-DD [default:
                                     (oldest)]
    -s, --state <state>              Only consider issues that have a particular state. [default: (any)]

ARGS:
    <json>    Required JSON file link (local or from GitHub API).

If you're looking for specific issues, you can specify a label to search for when parsing the JSON file. You can also constraint the output between two dates, or only look for closed/opened issues.

issue-tracking's People

Contributors

Stargazers

Watchers

issue-tracking's Issues

Install dependencies for offline use

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.

Fix Clippy CI fails

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

Handle pages when retrieving the issues

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.

Improve error management

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.

Request JSON from GitHub API

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.

Create `build.rs` for installation

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).

Introduce filtering capabilities

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

Run `clippy` on project

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

Issues met during usage

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.