Incorrect latest version on ejabberd

[bowlofeggs]

I noticed that I hadn't gotten a notification for ejabberd updates in a while. Anitya has 20.03 as the latest release:

https://release-monitoring.org/project/667/

However, there have been 4 releases (20.04, 20.07, 20.12, and 21.01) since then:

https://github.com/processone/ejabberd/tags

[Zlopez]

Hi @bowlofeggs, this definitely looks like bug. I will look at it more closely, when I will have some spare time. I have some suspicion, where this could be, but I need to verify it first.

[Zlopez]

I finally found some time to get back to Anitya and I found out, that the issue is in the GitHub cursor. To prevent reaching the API rate limits we are using cursors for GitHub projects to receive only newer versions than the last retrieved using the cursor provided by GraphQL API. In this case the cursor value was a non-sense, not sure how this happened. When I tried to delete the cursor in my local instance it worked.

This issue should be solved by two ways:

• Add option to reset the cursor
• Use date instead of cursor (this looks like better solution, because the cursor looks unreliable)

If you want to know more, here is my captain's log for the investigation:

   * Start the Anitya in test environment
     `vagrant up && vagrant ssh`
     `systemctl --user start anitya`
     Update config with github token and add myself as admin
     `systemctl --user restart anitya`
   * Check for new version for ejabberd project
     Do `Test check` on ejabberd project
     No new version retrieved, but there are definitely new versions on GitHub
     https://github.com/processone/ejabberd/tags
     This looks like the GitHub cursor is set to non-existing tag
   * Remove cursor position
     `sudo -u postgres psql`
     `\connect anitya`
     `UPDATE projects SET latest_version_cursor=NULL WHERE id=667;`
   * `Test check` for new versions
     Retrieves the new versions
     Probably the root of this issue is that there was tag that was retrieved by Anitya
     and later changed or deleted, so the cursor couldn't be found and the GitHub didn't
     respond with any new version 

[Zlopez]

I found out, that using the date for filtering is not possible in GraphQL API, so I would probably go with limit to last 50 tags, which will still consume only 1 point from rate limit. Not sure if I should check even older releases, but I think the older ones doesn't matter for release monitoring, just the latest. So the solution for this will be to remove the cursor completely and just retrieve the last 50 tags/releases from the project and use them.