chore(CI): device log artifacts, soft-fail retries, bump deps [WIP]

[mikehardy]

Description

The E2E tests are flaky right now, and it is hard to diagnose problems with android emulator or ios simulator

This PR is a taste-test - if it is acceptable I can re-push with the same style templated across the other modules

Changes are:

• emulator and simulator logging is captured and uploaded as workflow artifact
• all soft-fails (e.g., steps susceptible to transient network errors) are retried
• current version of cancel action inside a workflow, eliminates "magic" workflow numbers in separate cancel.yaml
• bump checkout version

Note that this style has been tested heavily after a concerted effort to de-flake the E2E CI in react-native-firebase

Related Issues

I have not been watching this repo, unsure if there are issues logged, but I have already seen a gradle network failure, and an e2e test app crash just on the 2 PRs I've tried here, each of which would have been addressed by this PR

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (flutter analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.

[mikehardy]

@Salakar this is a taste check for whoever the CI-master is in this repo - I didn't want to clone-stamp across the other modules unless it was acceptable, but it's almost all the tricks I put in place in RNFB CI except the multi-try on emulator, but the emulator retry is concise here so didn't want to touch that.

[mikehardy]

Apparent lack of interest, closing

[Salakar]

Apparent lack of interest, closing

Definitely interested, we just wanted to get past null-safety which we have now. Let's discuss internally :)

[mikehardy]

Implementation idea to push improvements through:

we could do it in stages first but across all workflows, e.g. update action versions first, add in logs capture and output artefacts, then figure out retries