Replace imgur?

[probonopd]

We have been using imgur to host the screenshots made by our automated tests.

But imgur has been giving errors for a while, blocking several successfully tested apps from being merged:

<code>1025</code><message>Too Many Requests</message><type>ImgurException</type><exception></exception>

https://github.com/AppImage/appimage.github.io/pulls?q=is%3Apr+is%3Aopen+imgur

Any replacement would be welcome.

[AshBuk]

Hi @probonopd !

Imgur is currently returning 1025 (Too Many Requests), which blocks PRs.
One option could be moving screenshot hosting to GitHub Pages for stable, long-lived URLs under project control. This could be done either via a dedicated repo (e.g., AppImage/screenshots) or a gh-pages branch in this repo. Some considerations include giving GitHub Actions write permissions and handling existing Imgur links during the transition.

[huanguan1978]

AppImage Submission Issue - Proposed Solutions for Minimizing API Requests & Cost-Efficiency

@probonopd

Thank you for acknowledging the issue. Given the "Too Many Requests" error and our "open-source, open-savings" ethos, I propose prioritizing minimal API requests for screenshot handling to enhance sustainability:

1. Strict HEAD Requests for Core Validation: When verifying the primary screenshot URL, use an HTTP HEAD request. This validates existence/accessibility with minimal overhead, directly addressing the "Too Many Requests" issue by avoiding full resource download.

2. Direct Referencing & Selective Processing for Display: For appimage.github.io display, which typically features the app icon and a single default screenshot, we should implement the following:

   • Prioritize Default Screenshot (Validate Only): Only validate the image URL within the <screenshot type="default"> tag in AppStream metainfo.
   • Directly Reference; Avoid Re-hosting: Directly embed this validated URL on the frontend. Critically, do not re-host or re-ingest this image, eliminating associated storage, bandwidth, and API calls.
   • Ignore Other Screenshots: Explicitly skip processing or requesting additional screenshot URLs. Their presence in AppStream can be noted, but no further API calls (validation, re-hosting, etc.) should be made.

This strategy ensures essential functionality with the fewest possible API calls, aligning robustly with both error mitigation and our commitment to lean, sustainable open-source infrastructure.

[probonopd]

Thanks for your suggestions. The screenshot from AppStream is used for appimage.github.io if it exists. However, we still need to see the screenshot from the automated test, since a visual inspection of it it is part of passing the test.

So, I'd appreciate a pull request that would use some other way to store the screenshot.

[AshBuk]

@probonopd
A possible solution would be to create a dedicated public repository, for example:
AppImage/screenshots

We can enable GitHub Pages on its default branch and use it to serve stable, long‑lived public URLs without API rate limits. GitHub Actions in appimage.github.io would need permission to push to that repository (contents: write) or a repo‑scoped PAT in secrets. The CI would upload the generated screenshots into structured paths (e.g., /.webp) in that repo, and the catalog would reference them directly.

• upload (from appimage.github.io) → dedicated repo AppImage/screenshots
• links → only the base URL changes
• Imgur can remain a temporary fallback (if desired)

If this approach sounds acceptable, I can open a small PR here adding the uploader (Bash/JS/Go — whichever you prefer) and a CI workflow that publishes to the new repository.

[probonopd]

Thanks @AshBuk. I think that would be quite a lot of overhead/overkill.

If one uploads a picture to a GitHub Pull Request, it also gets hosted at an URL. Could we automate this approach?

[AshBuk]

@probonopd Manual upload to a PR produces a GitHub-hosted URL, but there’s no public API to upload images to comments automatically.
We can use either a Release Asset or a small branch with raw URLs to get the URL for CI.

CI workflow flow:

1. CI generates the screenshot on pull_request.
2. Publish the screenshot:- Release Asset: download artifact -> create/reuse a draft release (ci-screenshots) -> upload the image as a release asset (image/png or image/webp) -> bot posts PR comment with ![](asset-url).

• Or separate screenshots branch: store the file at pr-/.webp -> link via raw.githubusercontent.com in PR comment (this should be more stable, but I'm not sure).

Both approaches might work for forked PRs, require no extra repo, and give reviewers inline images.
If this works for you (GitHub-only approach), ping me and I’ll propose a workflows example.

[probonopd]

@AshBuk I think I like the first approach best. Would appreciate a PR. Thanks!

[AshBuk]

@probonopd PR #3573 ready for review and testing.