valeriobelli / gh-milestone Goto Github PK

Description
It appears that jq query is not parsed properly:

when filtering with native jq it works

➜ gh milestone list --state all --first 1 --output json | jq ".[].Title"
"2.38.0"

but with --jq parameter it doesn't

➜ gh milestone list --state all --first 1 --output json --jq ".[].Title"
Usage: gh milestone list [flags]

Flags:
  -f, --first string                          View the first N elements from the list (default "100")
  -h, --help                                  help for list
  -j, --jq string                             Filter JSON output using a jq expression in combination with --output=json
      --orderBy.direction orderBy.direction   Use the defined sorting direction: {asc|desc} (default asc)
      --orderBy.field orderBy.field           Sort the milestones by a field: {created_at|due_date|number|updated_at} (default number)
  -o, --output output                         Decide the output of this command: {json|table} (default table)
  -q, --query string                          View milestones by string pattern
  -s, --state state                           View milestones by their state: {all|closed|open} (default open)

invalid character at position, 0; [

Current behavior

➜ gh milestone list --state all --first 1 --output json --jq ".[].Title"
Usage: gh milestone list [flags]

Flags:
  -f, --first string                          View the first N elements from the list (default "100")
  -h, --help                                  help for list
  -j, --jq string                             Filter JSON output using a jq expression in combination with --output=json
      --orderBy.direction orderBy.direction   Use the defined sorting direction: {asc|desc} (default asc)
      --orderBy.field orderBy.field           Sort the milestones by a field: {created_at|due_date|number|updated_at} (default number)
  -o, --output output                         Decide the output of this command: {json|table} (default table)
  -q, --query string                          View milestones by string pattern
  -s, --state state                           View milestones by their state: {all|closed|open} (default open)

invalid character at position, 0; [

Expected behavior

➜ gh milestone list --state all --first 1 --output json --jq ".[].Title"
"3.75.0"

Environment:

• OS: Ubuntu 20.04.5 LTS
• Shell: zsh 5.8 (x86_64-ubuntu-linux-gnu)

Is your feature request related to a problem? Please describe.
There is no clean, idiomatic way to grab all the milestones from a repo. First is always applied, and it needs to be overwritten; however, it cannot go over a value of 100 without erroring.

Is this limit due to GitHub CLI? Is it still a real limit? Is there any way to paginate and append all the results together? I know the GitHub API has a paginate flag. Currently, I have abandoned using this extension due to this limit.

Describe the solution you'd like

• gh milestone list --all - This is very idiomatic and describes what is wanted clearly.
• gh milestone list - This is very idiomatic and describes what is wanted clearly. I don't specify a limit, so it isn't limited.

Describe alternatives you've considered

• gh milesone list --first 99999 - Set First to some arbitrarily large number.
• gh milesone list --first 0 - Set First to zero. Instead of returning no milestones, this would default to Int.max
• gh milesone list --first -1 - Set First to negative one. I think the codebase requires a positive int, though. However, it's the same idea as setting it to zero.

However, setting values above 100 results in an error...
Requesting 99999 records on the `milestones` connection exceeds the `first` limit of 100 records.

Description
When doing an edit or create. I get a return of bad credentials.

Current behavior
When doing an edit or create. I get a return of bad credentials.

Expected behavior
I expect them to create or edit like I can in the UI

Environment:

• OS: MAC 10.12.4

Additional information
I'm able to edit and create in the UI.

Description

Can't edit milestone text

? Description [(e) to launch nvim --wait, enter to skip] nvim: Unknown option argument: "--wait"

Current behavior

This line calls the user's editor with the argument --wait, which is non standard. This argument belongs inside the EDITOR variable or in a shim, but not in this project.

Expected behavior

The editor opens, I can type text and when I exit the editor the milestone creation resumes

Environment:

• OS: macOS

Is your feature request related to a problem? Please describe.

Currently, the list subcommand exposes the output option to decide which kind of output the command should emit. This command adopts only two kinds of output:

• tabular
• JSON

The usages are the following one

$ gh milestone list
$ gh milestone list --output json

which is different from the other subcommands, as for example pr

$ gh pr list --json

Describe the solution you'd like

Given the list subcommand exposes a different interface compared to the other list subcommands and given the option jq works exclusively with a json output, start exposing this kind of output with the option json as done for the other list subcommand.

Describe alternatives you've considered
None.

Additional information/context
None.

Is your feature request related to a problem? Please describe.
Some subcommands have options that are not validated nor admit case-insensitive values. This makes the user experience a bit sloppy. For example, a developer could use gh milestone list --orderBy.direction=foobar to get an error afterwards because the GraphQL query errored.

Describe the solution you'd like

1. Let the subcommands' options get the correct values by validating the values used. If the value is invalid, the subcommand must show an error message. This behaviour would prevent the users make errors due to typos.
2. Let the subcommands' options get case-insensitive values.

Describe alternatives you've considered
None.

Additional information/context
None.

View milestons by states (default [OPEN])

1. There's a typo here ("milestons" should be "milestones")
2. It is case sensitive (only OPEN/CLOSE, not open/close), whereas gh issues list is case insensitive when filtering for state
3. It doesn't accept ALL/all (similar to how "issues" list supports) apart from "OPEN" and "CLOSE"

Description

The edit subcommand fails when strings with mixed cases are used (e.g., ClOsEd) for State flag.

Description
When I do gh milestone view 1, the text in the terminal changes from black to gray, which persists for following commands. Issuing another gh milestone command returns the font to black.

Current behavior

Expected behavior
Command prompt should remain in original text color

Environment:

• OS: MacOS
  Installed by homebrew
  gh version 2.21.2 (2023-01-03)
  https://github.com/cli/cli/releases/tag/v2.21.2

Additional information

Description
with this command:
gh milestone --list --repo xxx --query "name" --state closed --json title,number,id --jq ".[].id"
it prints also the repo address, and the id overwrite the first chars of the repo name

Current behavior

Expected behavior
just the id as output without the repo address

Environment:

• OS: powershell on windows 10

Additional information

Describe the solution you'd like

gh milestone -R cli/cli list

Additional information/context

The -R option works on all gh commands. It is useful when not in the git workspace.

Description
When I try to create a new milestone and assign the due-date at command line, the milestone created has a due-date on day sooner.

Current behavior

Creating milestone in ProjectTorreyPines/QED.jl

https://github.com/ProjectTorreyPines/QED.jl/milestone/1
Lyons% gh milestone view 1
test OPEN - 0% complete
Due by 2023-1-21 - Last updated at 2023-1-11

This is a test

Expected behavior

Lyons% gh milestone create --title test --description 'This is a test' --due-date 2023-01-22
Creating milestone in ProjectTorreyPines/QED.jl

https://github.com/ProjectTorreyPines/QED.jl/milestone/1
Lyons% gh milestone view 1
test OPEN - 0% complete
Due by 2023-1-22 - Last updated at 2023-1-11

This is a test

Environment:

• OS: MacOS
  Installed by homebrew
  gh version 2.21.2 (2023-01-03)
  https://github.com/cli/cli/releases/tag/v2.21.2

Additional information

Token storage change in latest release of gh

This is a message from the GitHub CLI team, maintainers of gh, writing to inform you that the most recent release of gh contains changes which may affect your extension. The latest release introduces the feature of storing authentication tokens in the system keyring (encrypted storage) instead of in a plain text file.
The keyrings that are supported are:

• Keychain on macOS

• GNOME Keyring on Linux (Secret Service dbus interface)

• Wincred on Windows

This has huge security benefits for the users of our tool and was one of our oldest outstanding issues. Unfortunately this change has the potential to break extensions that rely on utilizing the users authentication token to work.

In order to have continued compatibility with gh there are some actions you, as an extension author, need to take. These actions will depend on the implementation of your extension.

Extensions built in Go using go-gh:

1. Upgrade your go-gh version to v1.2.1, the latest version.

   • This can be done using go get github.com/cli/[email protected]

2. Verify that in your extension retrieval of the user authentication token is done using the auth.TokenForHost function.

   • If you were previously accessing the authentication token using any other method it will no longer work.
   • Automatic resolution of the authentication token when using the API clients will continue to work without changes.

All other extensions:

1. Verify that in your extension retrieval of the user authentication token is done by shelling out to the gh auth token command.

   • If you were previously accessing the authentication token using the gh config get command, reading the configuration file directly, or any other methods it will no longer work.

As of right now storing the authentication token in the system keyring is an opt-in feature, but in the near future it will be required and at that point if the changes above are not made then your extension will be broken for all users. If you have any questions/concerns about this change please feel free to open a discussion in the gh repo.

Thanks,
The GitHub CLI Team

Describe the solution you'd like

It would be nice if the json output could include the count of open (and closed) issues for the milestone. That way, I could use it to identify milestones that can be safely closed (past due, with no open issues).

Describe alternatives you've considered

The progressPercentage field is not sufficient for this use case. A milestone with no open or closed issues will show 0 progress, as will one with a non-zero number of open issues but no closed issues. The former is safe to close, the latter is not.

Thanks for considering this.

Milestone titles are unique, so no two milestones can share the same title.

I noticed that when running gh milestone edit it required the milestone identifier to edit a particular milestone, so I had to go to the GitHub UI to (or use gh milestone list with some jq magic) to extract the ID and then re-run gh milestone edit, which was really cumbersome.

Would it be possible to allow editing by milestone title, and let gh-milestone take care of resolving the ID for that particular title under the hood?

I'm trying to list issues per milestone, I've had progress with
cli/cli#6178

gh-milestone extension isn't used there, but it could as well have been used to get the list of milestone names that is done in the first step of the iterative solution

I have the issue that the milestones are returned in an order for which I can't specify sorting. In specific I'd like to do semantic version SORTING that the bash "sort -V" command can do but on DOS batch that I use there is no ready-made alternative for doing semantic sorting

Seems GitHub CLI supports sorting for other lists, can follow this path of discussions/docs on search's sort:
https://github.com/cli/cli/releases/tag/v1.8.0
https://cli.github.com/manual/gh_search_issues
https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests
https://docs.github.com/en/search-github/getting-started-with-searching-on-github/sorting-search-results

eg they have syntax:

`gh issue list -l "bug" --search "sort:interactions-desc"

they don't have a separate sort flag but do it via the search one

So similarly it would be nice to have something like

gh milestone list --search "sort:Version(title)"
or
gh milestone list --search "sort:title:version"
to treat the milestone title as a version string

(code would have to use some semantic version sorting routine though, since GitHub API doesn't seem to have sorting by a "semantic" string)