Ad-hoc builds sometimes have the completely wrong code

[chuckdries]

testBuild.yml seems to rely on Rock's fingerprint to uniquely identify the native build artifacts for ad-hoc builds, which causes a cache collision across different PRs that happen to have the same native code. This leads to ad-hoc builds on one pr actually containing code from a different PR.

For example, #81437 (comment) and #79473 (comment) are ad-hoc builds on completely different PRs, but link to the exact same S3 URLs

Issue Owner

Current Issue Owner: @LukasMod

[AndrewGable]

For additional context: The web build worked correctly in the examples above, iOS shows identical S3 URLs after code has changed.

[LukasMod]

Hi! I suspect the issue happened because we started building ad-hoc builds more frequently (on push to main), and I accidentally allowed them to run in parallel, which doesn’t work well with Rock internals. The gh action checks whether a specific build already exists, and when we re-sign (which we do in these workflows), we add the commit hash to the build name.

So instead of
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-FINGERPRINT/index.html

it ends up being more like
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-SHA-FINGERPRINT/index.html

In your case, I assume the build was replaced by another parallel build with the same native changes. This shouldn’t happen again, as the fix was merged a few hours ago.

One thing I’m not sure about right now is why the subsequent builds didn’t work for you, since they’re already using the SHA in the name. I’ll try to figure this one #79473 (comment) out

[LukasMod]

I prepared another fix to put both adhoc workflows (manual + push) into the same concurrency group. Previous fix was focused on new workflow instead of both #81520

[LukasMod]

I may found potential bug with manual triggered workflows.
It looks like in https://github.com/Expensify/App/actions/runs/21695712840 workflow was triggered for PR 79473, which set REF and properly checkout to create build, but after all it is saved based on GITHUB_SHA pointing to commit from main which triggered workflow:

• Main was at commit 4d4f242, therefore GITHUB_SHA = 4d4f242 for the ENTIRE workflow run

• Checkout action checks out ee673a9 (from needs.prep.outputs.APP_REF based on PR number)

• The working directory HEAD is now ee673a9, building

• GITHUB_SHA context variable still equals 4d4f242 so https://github.com/callstackincubator/ios/blob/8dcef6cc275e0cf3299f5a97cde5ebd635c887d7/action.yml#L416-L429
  sets ARTIFACT_NAME to rock-ios-device-AdHoc-4d4f242-54e89147d28f8e8638773d8a678888d5d25e206b

• there is a risk that another workflow may be also triggered for the same GITHUB_SHA and same fingerprint

[LukasMod]

But even if that’s true, the build was triggered again, so it should have been overwritten or created from scratch after the manual deletion. I’m a bit worried there might be something else going on too.

There was similar build triggered 15min later from #81465,
which produced ios artifact link: https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-4d4f242-54e89147d28f8e8638773d8a678888d5d25e206b/index.html - same as build from this comment #79473 (comment). But based on timings in responses it should not be issue, it was already marked as wrong one (10min before second build finished) 🤔