Fix react-native-prompt-android package integration

[fluiddot]

gutenberg PR: WordPress/gutenberg#32189
[Only for testing] WPAndroid PR: wordpress-mobile/WordPress-Android#14713

This PR includes an update of react-native-prompt-android for fixing a crash on Android (related PR).

To test:

1. Open a post/page
2. Observe that the app doesn't crash

PR submission checklist:

• I have considered adding unit tests where possible.
• I have considered if this change warrants user-facing release notes more info and have added them to RELEASE-NOTES.txt if necessary.

[peril-wordpress-mobile]

Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job!

[jd-alexander]

Approved via WordPress/gutenberg#32189 (review)

[cameronvoell]

Hi @jd-alexander @fluiddot - I added a cache-version file because the failure in RN Bridge Publish to S3 job had a failure that requires a new commit hash. I took the idea for the cache-version file from WordPress-iOS (see here). See the error message below.

Error:

* What went wrong:
Could not determine the dependencies of task ':react-native-aztec:publish'.
> Could not create task ':react-native-aztec:checkIfVersionIsAlreadyPublished'.
   > '3548-e23ca05e7321d59f62b8cc10812bd6ece38bf58f' is already published, please use a different version name. If this happened in CI for a PR, a new commit is necessary.

[jd-alexander]

Hi @jd-alexander @fluiddot - I added a cache-version file because the failure in RN Bridge Publish to S3 job had a failure that requires a new commit hash. I took the idea for the cache-version file from WordPress-iOS (see here). See the error message below.

Nice! Good thinking @cameronvoell 🙇🏾

[fluiddot]

Hi @jd-alexander @fluiddot - I added a cache-version file because the failure in RN Bridge Publish to S3 job had a failure that requires a new commit hash. I took the idea for the cache-version file from WordPress-iOS (see here). See the error message below.

Error:

* What went wrong:
Could not determine the dependencies of task ':react-native-aztec:publish'.
> Could not create task ':react-native-aztec:checkIfVersionIsAlreadyPublished'.
   > '3548-e23ca05e7321d59f62b8cc10812bd6ece38bf58f' is already published, please use a different version name. If this happened in CI for a PR, a new commit is necessary.

Awesome! Thanks @cameronvoell for adding it!

Does the cache-version file reset the CircleCI cache too? If it's only a matter of making a commit to trigger the PR checks, a command I usually use is git commit --allow-empty -m "Trigger PR checks" that basically adds an empty commit.

[hypest]

Aha, the "cache-version" trick is a cool one. If we continue with it I'd only propose to not call it "cache" at all to avoid confusion. In this case, it's only purpose is to trigger the S3 job and nothing else so, let's scope it's name down to just that :), something like "trigger-bridge-build-to-s3.txt". I know that modifying the file will cause all CI jobs to run again (which is overall unfortunate), but keeping the name scoped down and hope to remove the need in the future is what I'd shoot for.

[fluiddot]

Aha, the "cache-version" trick is a cool one. If we continue with it I'd only propose to not call it "cache" at all to avoid confusion. In this case, it's only purpose is to trigger the S3 job and nothing else so, let's scope it's name down to just that :), something like "trigger-bridge-build-to-s3.txt". I know that modifying the file will cause all CI jobs to run again (which is overall unfortunate), but keeping the name scoped down and hope to remove the need in the future is what I'd shoot for.

I'm not sure about using the name of the job that we want to trigger as technically we would trigger all of them, don't you think?

What would be the benefit of having a file vs pushing an empty commit?

[hypest]

What would be the benefit of having a file vs pushing an empty commit?

Sorry, I'm not actually advocating for the file-based approach :), hence the "If we continue with it" in my message above. I was only commenting on the name of the file. We already have a CircleCI environment variable to trigger cache reworks and having a similarly named file will add confusion.

Personally, I think the empty commit approach is cleaner and more scoped-down in its messaging. Let's go ahead with reverting the file. We can reinstate if needed. @cameronvoell , reading your message about it, it doesn't look like the file isn't trying to accomplish a goal beyond triggering the jobs, right? If there's an additional goal we can reinstate.

[fluiddot]

What would be the benefit of having a file vs pushing an empty commit?

Sorry, I'm not actually advocating for the file-based approach :), hence the "If we continue with it" in my message above. I was only commenting on the name of the file. We already have a CircleCI environment variable to trigger cache reworks and having a similarly named file will add confusion.

No worries, in fact, I didn't want to mean that you were advocating for that approach, sorry for mixing both things in the same comment 😄 .

Regarding the file name, I agree with your comment, use the word cache could be misleading if it's not really related to cache logic. In case we continue with the file approach, I also advocate finding a different name 👍 .

Personally, I think the empty commit approach is cleaner and more scoped-down in its messaging. Let's go ahead with reverting the file. We can reinstate if needed. @cameronvoell , reading your message about it, it doesn't look like the file isn't trying to accomplish a goal beyond triggering the jobs, right? If there's an additional goal we can reinstate.

Ok, I'll revert the file in the meantime but I'll be more than happy to restore it if we consider that it serves more purposes apart from re-triggering the jobs.