DiUS/pact-consumer-swift

Include binaries of depending tools in the repo

surpher opened this issue · 3 comments

surpher commented

When running in CI/CD (TravisCI) in our case, it is not encouraged to update tools on the Build machine to the latest as the may break the version dependency (eg: brew update, carthage update). These updates might update the dependencies or behaviour that might not be compatible with the codebase. By bundling these binaries we can be sure the environment on developers machine and CI are the same.

Suggesting to bundle the following binaries of tools into the repo:

  • Carthage
  • Swiftlint
  • Pact-Mock-Service

- Carthage dependencies

Scripts and steps that use these tools need to be updated to use these specific binaries instead of tools installed on developer's machine or CI agents.

andrewspinks commented

We can pin version dependencies if necessary, but I don't really like having binaries in the repo.

  • 👍1
surpher commented

Oh, the Carthage/Pod Dependencies shouldn't have been on the list above.

But, hear me out here...

Running brew update, install _tool_ and such messes up the environments and is mostly always makes them different between a developer's and the environment on the build agent.

Example 1:

  • fastlane installed using homebrew on my machine.
  • using scan to run tests works fine
  • using scan step in TravisCI doesn't work but requires fastlane scan

Example 2:

  • xctool installed locally
  • works with test
  • doesn't work on TravisCI but works with run-tests

I agree it's a divisive proposal. Bloats up the repo, true.
But it also simplifies the onboarding as there are less "right" version of dependencies to sort out (clone > build > run, instead of clone > build > fail > find the correct version of swiftlint, find the correct version of pact-mock-service, stick the tool in the right place, figure out why it is still failing,...).
It simplifies the maintenance of a repo that is touched only every now and then when it falls behind.

andrewspinks commented

Yeah, I get your point. I think we could achieve that with an install script that can be run by ci and anyone picking up the project. We can pin the versions in the script as needed.

  • 👍1