I've been seeing a few issues where the E2E tests would pass but the job would fail during the upload-artifacts step, I think it might be an issue with GitHub Actions itself but for now, I think we should only upload the artifacts if it fails.

@geriux It might be an edge case, but I think the video captured while running the tests can be useful to double-check that the test succeeded, in case of potential false positives like visual regressions. Probably this won't be an issue when we incorporate visual regression tests, but until then, I'm a bit hesitant to only upload the artifacts when the test fails.

Regarding the upload failure, if it's an infrastructure issue, I understand that it will be temporary, isn't it?

@geriux It might be an edge case, but I think the video captured while running the tests can be useful to double-check that the test succeeded, in case of potential false positives like visual regressions.

I'm not sure if I understand it correctly but the video will be recorded but it won't be uploaded to GitHub unless the tests fail.

To be honest I never check these videos unless something fails 😅

Regarding the upload failure, if it's an infrastructure issue, I understand that it will be temporary, isn't it?
I'm not really sure, we could wait and see, but just noting will be having E2E failures for now.

I'll have this PR open just in case it gets worse and it blocks development in the repo.

I'm not sure if I understand it correctly but the video will be recorded but it won't be uploaded to GitHub unless the tests fail.

So, if the video is not uploaded then we won't be able to check it in the PR, is this accurate?

To be honest I never check these videos unless something fails 😅

To be honest, I don't check it regularly and when I do is mainly on failed tests. Nevertheless, leaving a trace of what happened via a video might be interesting. I don't have a strong opinion on uploading it on successful runs, so in case this change helps to stabilize the E2E tests we can go with it.

I'll have this PR open just in case it gets worse and it blocks development in the repo.

👍

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core.
• Labels found: [Status] Stale, Mobile App - i.e. Android or iOS.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

Closing this as Stale.