thyrlian
commented
3 years ago First of all, thanks @alindaj6 for your contribution, this PR fully complies with the contributing guide, and all checks have passed.
Before considering merging it, I'd like to ask about the intention and the approach.
As you've described, it's for the sake of fastlane. Fastlane has been there for years, getting quite popular and mature, especially for iOS development. Though I'm not sure how many developers use fastlane for Android development, supporting it would be definitely great!
Regarding the approach, I've checked the image you've created, it includes ruby environment and bundler gem only, without fastlane. Here are some facts we have to think about:
- A Docker image for fastlane purpose but without preloading fastlane is not complete
- Fastlane releases very often, and every team has different requirements in terms of versions, thus we can't provide them countless versions of fastlane.
- Some teams prefer ruby as their glue language, to perform some other jobs. Therefore, this image would be handy for them because of preloaded ruby environment, apart from fastlane. That's why I hesitate - should we name the image ruby or fastlane? For sure not bundler, because it's not as meaningful as the other two.
Bearing in mind the 2nd point - "countless versions of fastlane", I've come up with another idea, what about providing a Dockerfile instead of a built image? For instance, if we leave a placeholder for fastlane version in the Dockerfiler, which allows developers to pass any certain version of fastlane as a build argument. In this way, we can still "provide" a complete image with fastlane, while leave the freedom to developers regarding the fastlane version. All they have to do is to trigger the build command.
What do you think?
Add bundler for working with fastlane