Feat: Limit the number of versions retrieved by command generate and update. Sovle issue #2355

[dreamjz]

Solve issue #2355.

Description

• Add --limit/-l flag for aqua generate and aqua update.
  • The default limit is 30.
  • --limit -1 refers to no limitation.

PS: Because of aqua update using versiongetter.FuzzyGetter, so I modified the aqua update command at the same time.

Test Cases

aqua generate

# Using -s with the default limit
$ aqua g -s cli/cli
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 30/30

# Using -l to set limit 
# -1 refers to no limitation
$ aqua g -s -l -1 cli/cli
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 115/115
# negative number also refers to no limitation 
$ aqua g -s -l -999 cli/cli
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 115/115
# limit 0, using default limit
$ aqua g -s -l 0 cli/cli
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 30/30
# limit 5 versions
$ aqua g -s -l 5 cli/cli
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 5/5
# limit 200, greater than the total number of versions 
$ aqua g -s -l 200 cli/cli
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 115/115
# other cases
$ aqua g -s -l 114 cli/cli
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 114/114

aqua update

# Using -s with the default limit
$ aqua up -s gh
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 30/30
 
# Using -l to set limit 
# -1 refers to no limitation
$ aqua up -s -l -1 gh
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 115/115
# negative number also refers to no limitation 
$ aqua up -s -l -999 gh
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 115/115
# limit 0, using default limit
$ aqua up -s -l 0 gh
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 30/30
# limit 5 versions
$ aqua up -s -l 5 gh
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 5/5
# limit 200, greater than the total number of versions 
$ aqua up -s -l 200 gh
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 115/115
# other cases
$ aqua up -s -l 114 gh
   ...
   v2.36.0 
   v2.37.0 
 > v2.38.0
 114/114
$ aqua up -i -s -l 3
> cli/[email protected]
  1/1
...  
   v2.36.0 
   v2.37.0 
 > v2.38.0
 3/3 

[suzuki-shunsuke]

Thank you for your contribution!

[dreamjz]

It seems there are some errors here.
Do I need to make modifications and re-create PR?
Sorry, this is my first PR

[suzuki-shunsuke]

You don't need to recreate PR.
Please push new commits to fix errors.
Please don't do force pushes.

[dreamjz]

Description

• Remove code that could result in version data loss
• If there are filters to be used, per_page will be ghMaxPerPage to filter as much data as possible
• Fix the lint issue

Additional Modification

• Use github.Response for pagination

Issue

When using opt.Page (start with 0) for pagination, the content of page 0 and page 1 will be the same.

According to GitHub API Docs/Release#list-releases, the page starts with 1.

# Releases
$ curl -s "https://api.github.com/repos/cli/cli/releases?per_page=3&page=0" | grep 'tag_name'
    "tag_name": "v2.38.0",
    "tag_name": "v2.37.0",
    "tag_name": "v2.36.0",
$ curl -s "https://api.github.com/repos/cli/cli/releases?per_page=3&page=1" | grep 'tag_name'
    "tag_name": "v2.38.0",
    "tag_name": "v2.37.0",
    "tag_name": "v2.36.0",
$ curl -s "https://api.github.com/repos/cli/cli/releases?per_page=3&page=2" | grep 'tag_name'
    "tag_name": "v2.35.0",
    "tag_name": "v2.34.0",
    "tag_name": "v2.33.0",
    
# Tags
$ curl -s "https://api.github.com/repos/golang/go/tags?per_page=3&page=0" | grep 'name'
    "name": "weekly.2012-03-27",
    "name": "weekly.2012-03-22",
    "name": "weekly.2012-03-13",
$ curl -s "https://api.github.com/repos/golang/go/tags?per_page=3&page=1" | grep 'name'
    "name": "weekly.2012-03-27",
    "name": "weekly.2012-03-22",
    "name": "weekly.2012-03-13",
$ curl -s "https://api.github.com/repos/golang/go/tags?per_page=3&page=2" | grep 'name'
    "name": "weekly.2012-03-04",
    "name": "weekly.2012-02-22",
    "name": "weekly.2012-02-14",

why not use opt.Page

• Using github.Response is the recommended approach for pagination in google/go-github#pagination

• It is also recommended in GitHub API Docs/Pagination#using-link-headers

• In my opinion, the readability of this approach is slightly improved

  if resp.LastPage == 0 {
  	...
  }
  opt.Page = resp.NextPage
  
  if len(releases) != opt.PerPage {	
  	...
  }
  opt.Page++	

[suzuki-shunsuke]

Using github.Response is the recommended approach for pagination in google/go-github#pagination

It looks good. Thank you!

[dreamjz]

This is a typo, but it works accidentally.

$ curl -s --include "https://api.github.com/repos/cli/cli/releases?per_page=100&page=1" | grep "link:" | grep "rel="         
link: <https://api.github.com/repositories/212613049/releases?per_page=100&page=2>; rel="next", 
<https://api.github.com/repositories/212613049/releases?per_page=100&page=2>; rel="last"

$ curl -s --include "https://api.github.com/repos/cli/cli/releases?per_page=100&page=2" | grep "link:" | grep "rel="         
link: <https://api.github.com/repositories/212613049/releases?per_page=100&page=1>; rel="prev", 
<https://api.github.com/repositories/212613049/releases?per_page=100&page=1>; rel="first"

$ curl -s --include "https://api.github.com/repos/cli/cli/releases?per_page=100&page=3" | grep "link:" | grep "rel="         
link: <https://api.github.com/repositories/212613049/releases?per_page=100&page=2>; rel="prev", 
<https://api.github.com/repositories/212613049/releases?per_page=100&page=2>; rel="last", 
<https://api.github.com/repositories/212613049/releases?per_page=100&page=1>; rel="first"

When the page is the last page, the rel="last" will not appear in link header.
But only NextPage can indicate that we reach the last page, so I'll fix it.

[dreamjz]

I've reconsidered about this and think that the 0 value for limit has no significance, so I delete the code for checking 0 value.

[suzuki-shunsuke]

Thank you!

[suzuki-shunsuke]

I'll release this by the end of the next Monday.

[suzuki-shunsuke]

aqua v2.17.0 is out 🎉

https://github.com/aquaproj/aqua/releases/tag/v2.17.0

Thank you for your contribution!