Webkit and Mobile safari are comically unreliable, will fail for unexplainable reasons and are very hard to run locally in comparison with the other supported platforms. I do not remember the last time where these two platforms were able to catch a regression where the other platforms did not.
I would like to stress, for the historical record, that many hours has been devoted into adjusting the tests and following best practices to make these two platforms more stable but despite those, IMO wasted, efforts these two platforms are causing many hours of wasted CPU time simply because they are flaky and make (new) contributors nervous if their change contains a regression or not.
To my knowledge, the tests are not broken for these two platforms. If you go to the issue tracker you will not find issues by users that use these two platforms and report that Forgejo is broken. It does not reflect reality.
This is the sunk cost fallacy, bite the bullet and agree that these platforms will not contribute positively to Forgejo's excellent test suite.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10103
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
* Add some test that only snapshot relevant content
* Allow adding marging around the element in case the environment is relevant (e.g. the location of an element relative to the parent, but excluding the environment of the parent)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9499
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Otto Richter <git@otto.splvs.net>
Co-committed-by: Otto Richter <git@otto.splvs.net>
- I cannot give a good rationale why Mobile Safari and webkit is failing this test quite consistently and also succeed quite often. We add a script to ensure that we get a mismatched URL - but these two browsers either ignore this script sometime or delays the execution until after the root URL check is done.
- Because it is very hard to run webkit and mobile safari without running a heavily containerized environment (without a graphical interface) it is near impossible to debug this issue properly; save ourselves a headache and disable it instead. I find it more likely to be a problem with my playwright test than it to be a problem with the mismatched root URL code.
- Ref forgejo/forgejo#8359
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8460
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
- In the case that the `ROOT_URL` does not match the site a person is visiting Forgejo gives zero guarantees that any of the functionality will still work.
- Make the error i18n, use `local_next`.
- Reflect in the error that the any part of the application can break, don't be specific - it is plain wrong and should not be used.
- Always check for this case on the login page. This was previously only the case if OAuth2 was enabled, but this code was checking for elements that are always present on the login page regardless if the OAuth2 was enabled or not. Technically nothing changed, but reading the code it is now more clear when this check is being run.
- Add E2E testing.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7103
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
