search

flathub-infra / flatpak-external-data-checker

A tool for checking if the external data used in Flatpak manifests is still up to date
GNU General Public License v2.0
115 stars 36 forks source link

Odd `rotating-url` behavior? #438

Open guihkx opened 1 month ago

guihkx commented 1 month ago

On the Discord repository, there have been many pull requests made by this bot that simply change the URL of a .tar.gz source back and forth, even though its sha256 sum never changes:

Additionally, the metainfo file is getting many duplicated <release> tags.

Maybe the bot shouldn't open a pull request if the hash of a source didn't change and it's not an extra-data type?

games647 commented 1 month ago

The War Thunder flatpak has the same issue, that forced them to disable auto-merge

Reference #373

wjt commented 1 month ago

On the Discord repository, there have been many pull requests made by this bot that simply change the URL of a .tar.gz source back and forth, even though its sha256 sum never changes:

The way the rotating-url checker works is that it fetches the given URL and keeps following redirects until it finds an actual file. Evidently sometimes this redirects to a URL that does not match the given pattern.

Maybe the bot shouldn't open a pull request if the hash of a source didn't change and it's not an extra-data type?

I would prefer "if the hash of a source didn't change and the old URL still resolves". Alternatively you might consider "ignore redirects that don't match the given pattern".

Fuseteam commented 1 month ago

another pr on discord's side xd https://github.com/flathub/com.discordapp.Discord/pull/444

games647 commented 1 month ago

@wjt

"if the hash of a source didn't change and the old URL still resolves"

This would mean that the file always have to be downloaded even if a version pattern is given. Although looking at the current code, this is the current behavior, this is not really a great solution for bigger applications to be re-downloaded for each check. Nevertheless, I created a PR that uses this solution: #439

Alternatively you might consider "ignore redirects that don't match the given pattern".

If we ignore those redirects, we might miss new releases. Especially in use cases where the provider will only use those URLs (01.download.example.com, 02.download.example.com) instead.