[Release-only] Fix the wrong test-infra branch on release/0.2

[huydhn]

#3020 is not needed, instead, the test-infra branch needs to be pinned to release/2.3

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/3021

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure

As of commit 5011977 with merge base d3326a2 ():

NEW FAILURE - The following job has failed:

• pull / test-models-linux (cmake, llava_encoder, portable, linux.4xlarge, 90) / linux-job (gh)
  RuntimeError: Command docker exec -t 436e55c265471c2ac54239da5da1234cd561372a6ef9d221ebc73a824604da8b /exec failed with exit code 1

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[mergennachin]

Oh awesome, thanks so much for finding this

[guangy10]

Thanks for the fix, Huy!

[guangy10]

I feel this is another example where cherry-picks override the release-only changes. Previous one is fixed in #3002. @huydhn do you have any suggestion how we can make the cherry-picking not overriding the release-only changes, or detect it somehow? cc: @dbort @mergennachin

[huydhn]

Atm, the cherry script run the command with -X theirs to avoid merge conflicts here https://github.com/pytorch/executorch/blob/main/.github/scripts/cherry_pick.py#L119. Maybe that logic could be removed to detect conflicts in this case? -X theirs means that the cherry pick PR will prefer whatever is from the original PR if there are conflicts with the release branch.

[guangy10]

Atm, the cherry script run the command with -X theirs to avoid merge conflicts here https://github.com/pytorch/executorch/blob/main/.github/scripts/cherry_pick.py#L119. Maybe that logic could be removed to detect conflicts in this case? -X theirs means that the cherry pick PR will prefer whatever is from the original PR if there are conflicts with the release branch.

@huydhn Good to know. Thanks for the info! I think removing -X theirs may not be ideal as it may end up lots of false alarm that we have to manually address. I'm thinking of something as simple as a disallowlist where we can either reject the changes (for example if cherry-pick requests are touching .github/workflow, or version.txt, etc) or raise as merge conflict (for example if changes are in setup.py, install_requirements.sh, etc. where we could allow refactoring but would still prefer to lock down to some fixed versions for stability).