Can we use bundler and a Gemfile instead for this here too? This is effectively using any for each the gem versions and will probably cause issues down the line, even if it appears to be working now. I think we could convert setup_script into an actual script file and echo the Gemfile out into the operating system from there and then run it similar to how the Dockerfile works.

Isn't it better if we fail fast if something breaks us upstream?

@jmagman do you have opinions?

In general yes, but this would be exposing us to unnecessary upstream breakages IMHO, especially because it's ignoring semantic versioning.

Let's assume that our CI works with the current versions of these packages. The way that this is currently written, if and when a bad (or even "good" but breaking) version n+1 of any of these gems are published, the Flutter tree will immediately go red because we will greedily pull in the new version even if it's got a bug or if it's a major version bump. Then we will have a fire and immediately have to diagnose and figure out a workaround for the broken upstream package. I don't think there's any reason for us to be using the absolute latest version of these packages at all times, is there? It seems like it would be better to bump the versions deliberately and test the version bumps through CI like everything else.

In addition to that bundler will handle transitive dependency installation and matching similar to how pub does. I don't think two successive sudo gem install commands do the same thing. So I think there's another potential breakage here where future versions of these packages have overlapping but potentially conflicting transitive dependencies, and the first install grabs a version that's incompatible with the second one.

Also, I think the reason why this initially failed was because we were using an old version of fastlane from our mac vm (essentially pinned to whenever the image was last created).

That's a good point. I'm concerned pinning fastlane will lead to this same breakage. But perhaps the lesser of two evils?

I would be surprised if an old version of fastlane that used to work suddenly spontaneously stopped working in a truly hermetic environment. It's more likely that something else in our environment changed and then broke with the version. I would rather we try to drive the environment towards general immutability so we can predict what's going on vs introducing more chaos in the system.

From reading the PR description though it sounds more like fastlane was getting implicitly installed by the OS, and the version that was getting installed that way was incompatible with one of our other dependencies which was itself being greedily installed to a random version so randomly broke. It's not necessarily that it was an older version, it's that it was a random one and that was combined with a random install of GCloud. If we were deliberately versioning all of the environment dependencies, we wouldn't be able to have anything surprise break based on a version bump like this. It's not so much that it was too old I don't think in that it was too unpredictable and changing outside of our PR review cycle.

I think we decided to try to use newest cocoapods since we were able to catch some issues like #41144. If we can express that in a Gemfile, then pegging xcpretty and fastlane to a tight version range seems like a good idea.

Got it. If we want the tree to turn red whenever cocoapods breaks because users will be using the latest, that makes sense. gem 'cocoapods' in the Gemfile would always grab the latest version.

I added a Gemfile (and Gemfile.lock), pinning down the version of fastlane and xcpretty, and having cocoapods be latest.