Refactor integration tests so they can be run locally

[armcknight]

Description

I have a problem on a PR with one of the integration tests, but don't see an easy way to run them locally without a bunch of manual steps.

I plan to write a couple makefile tasks to automate this.

A couple questions about the current implementation:

• Would anyone be opposed to forking the repos we use, applying our patch files as commits onto those forks, and linking them into this repo as submodules? That would eliminate a lot of the automation around apply-patch.sh.
  • The reason I looked at this is because I was trying to figure out why we do so much work around injecting commit SHAs. If we go the submodule fork route, we don't have to worry about any of that.
  • This would also avoid having to download the apply patch script separately from a specific git commit, chmoding it, etc. We could just use the version we have in the PR/master branch, and use it directly on the submodule.
  • This would also allow us to use a local podspec to integrate into the test apps, using the path directive instead of the commit directive used e.g. here. This would avoid a call over the network.
• Is there any other reason we have commit SHA injection? Are we ever running this on anything other than a PR or master? Would git rev-parse HEAD not work in all cases?

[brustolin]

The benefits of not forking is that we keep trying our SDK with new stuff when this other projects are updated.
But I dont have a strong option about this.
I understand that our current approach is not bullet prove.

[armcknight]

A benefit of forking would be that we could experiment with different things in topic branches in the forked repo and merge as we finalize an implementation, with PRs and everything. It would also allow rebasing our changes on top of updates from upstream; have we ever had to deal with conflicts in our patchfiles?

[philipphofmann]

I didn't create forks because I wanted to keep it lightweight. I just patched things together to make it work. Of course, a significant downside of the current solution is that you can't easily run it locally. If you want you can change it to what you suggested.

[armcknight]

I see where you're coming from, you got things working at the time you needed it. IMO it would be lighter weight to do away with the script, the downloading of files from our own repo into another, and finding/injecting commit SHAs into a patchfile template, and instead only need git clone/git submodule update.

[philipphofmann]

I would be interested in why you want to improve this. Do you have to touch that often, @armcknight? Is it worth the effort to improve this right now?

[armcknight]

It might not be necessary for my task right now, but if I have to do it again at any point I will want to just automate it then. In the meantime we can dump any other questions/concerns here.

[armcknight]

Integration tests were removed in #2916