feat: automatic fallback to tags for GitHub

[ThinkChaos]

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

Having to manually specify url_commands for GitHub repos that use tags, but not releases is slightly inconvenient.

Describe the solution you'd like

It would be nice if Argus could automatically fall back to tags if no releases exist for the service.
To do this without counting towards the API rate limit, the ETag could default to "1202860668f8cc09802a90038fa4ff8cdc642644697a3ef85aace4bd6ed91973" which is what GitHub returns for an empty list.
In case of 304 Not Modified, Argus should query the tags API and match the default regex against each ref stripped from the refs/tags/ prefix.

Here's an example tags API response:

[
  {
    "ref": "refs/tags/v0.1",
    "node_id": "MDM6UmVmMTU5NTU2Nzk0OnJlZnMvdGFncy92MC4x",
    "url": "https://api.github.com/repos/go-vikunja/api/git/refs/tags/v0.1",
    "object": {
      "sha": "0bf5a9412e9da205b118517f5e2844e7850b7661",
      "type": "tag",
      "url": "https://api.github.com/repos/go-vikunja/api/git/tags/0bf5a9412e9da205b118517f5e2844e7850b7661"
    }
  },
  {
    "ref": "refs/tags/v0.2",
    "node_id": "MDM6UmVmMTU5NTU2Nzk0OnJlZnMvdGFncy92MC4y",
    "url": "https://api.github.com/repos/go-vikunja/api/git/refs/tags/v0.2",
    "object": {
      "sha": "5f695c2af8871b303e8b76bac888d8d57d16a6fd",
      "type": "tag",
      "url": "https://api.github.com/repos/go-vikunja/api/git/tags/5f695c2af8871b303e8b76bac888d8d57d16a6fd"
    }
  }
]

I believe this would make almost any GitHub project work out of the box.

Describe alternatives you've considered

Manually specifying the url_commands for each such service works.

[JosephKav]

Doing queries now on https://api.github.com/repos/go-vikunja/frontend/releases, https://api.github.com/repos/go-vikunja/frontend/releases and https://api.github.com/repos/allinurl/goaccess/releases gives me the 992aaf92b487506974e4305db4a64326866f3ed48b2ba424cef8fbe4e28f72b0 ETag. Was it giving you 1202860668f8cc09802a90038fa4ff8cdc642644697a3ef85aace4bd6ed91973 when you tried last week?

I'm thinking that the ETag for empty releases isn't constant, so just do the first query with no ETag, and if that query on /releases gives an empty list, then switch that Service to /tags. Would double the API calls for repos using tags instead of releases, but only on the very first queries for each Service on startup

[ThinkChaos]

Trying again with Firefox I get the same ETag I had last week (1202...), but with curl I get the same one you do 992a....
Using Firefox's dev tools "copy as curl" I get a third ETag: 40d7791495f98777a75dd6d73d7794658c7df79d296af9c37bf97c9c3aa11ecc.
Hardcoding one of the "empty" ETags doesn't seem to have a downside so, if simple, why not? But as you said the cost is very low, so it's definitely not a big deal without either.
I just mentioned the ETag since I saw other requests use them :)

[JosephKav]

Ah, good that it's not changed in a week.
I'll add this as a default, and on startup, do a query with that default and update the default if that's changed. I'm also adding a check for a 200 response being an empty list (incase that etag changes whilst the app is running), and having that update the default and trigger the fallback query

[ThinkChaos]

Amazing, thanks!

I'll update and test later today :)
(Didn't get notified by the PRs, would've tested then otherwise!)

[ThinkChaos]

Works great, thanks!