tests: Add a way to skip the test involving mirroring screenshots

[smcv]

Some build and CI systems operate fully offline in order to avoid dependencies on remote services. Skip this test if environment variable FLATPAK_BUILDER_TESTS_OFFLINE is set non-empty.

[smcv]

Best reviewed with "Hide whitespace".

[swick]

Maybe I'm a bit confused here, but how does the test require network access?

[bbhtt]

appstream downloads the screenshots from metainfo to mirror them. Seems fine to me, but it technically just turns off the test.

Maybe in absence of network we can skip the "mirroring" part here and just test if flatpak-builder is managing to create the screenshot ref out of "files/share/app-info/media" ? Generating some junk files in that directory should do it I think.

[bbhtt]

Maybe in absence of network we can skip the "mirroring" part here and just test if flatpak-builder is managing to create the screenshot ref out of "files/share/app-info/media" ? Generating some junk files in that directory should do it I think.

Try testing #666

[bbhtt]

I went with #666 instead to keep the test working even without network, but I may use your variable idea to guard future tests that may need network.

[smcv]

appstream downloads the screenshots from metainfo to mirror them. Seems fine to me, but it technically just turns off the test.

Yes, from Debian's point of view it's fine if requesting offline testing results in reduced test coverage. Some is better than none.

The rule that's applied during build-time testing is that the tests are meant to not even attempt to access internet resources. We don't currently run flatpak-builder's tests at build-time anyway, because the build environment is sufficiently restricted that we can't run Flatpak, but if we did run them we'd prefer to have partial coverage and no attempts to download remote resources, rather than either full coverage or no coverage.

We do run the tests as an "autopkgtest" ("as-installed" testing similar to https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests), for which access to remote resources is allowed but strongly discouraged because of reliability concerns.