Is the plugin production ready?

[myniva]

This S3 build cache implementation for Gradle started as a proof-of-concept right when the build cache feature was first announced in Gradle 3.5. To warn potential users of issues which might exist, I've added a note to the readme regarding the beta state ("this plugin is not yet ready for production") of this plugin.

Unfortunately, I've never had the chance to use the plugin in a real world scenario. I am therefore still lacking any experience regarding the robustness of it. It is also hard to tell how widely the plugin is adopted in the wild.

Let's use this issue to discuss the current state of the plugin and which steps would be needed to release a first stable and production ready version 1.0 of it.

[erdi]

Hi @myniva. Sorry for a late response, this slipped through the cracks for me.

Thanks for starting this discussion. It's good to know that the note about this not being production ready has nothing do to with any known deficiencies of the implementation and that you've added it just because you were not able to battle test it.

I will take it for a spin in the upcoming weeks and see how it works for us. I also know from twitter that Sergei Egorov (https://github.com/bsideup) is using it in testcontainer's build.

After looking at the code, the only thing that comes to my mind with regards to things that are potentially missing is an eviction/expiry strategy so that the cache does not grow infinitely as it might generate significant costs on your AWS invoice. Do you have any other features in mind you would like to add before 1.0?

[myniva]

Hi @erdi, thanks for joining the discussion.

I would highly appreciated some more thorough testing of the plugin before we officially release v1.0. @bsideup, would you mind sharing the experience you had so far with this plugin here? That would help us to get a better understanding how stable it is.

Expiration of objects did come to my mind as well, see #1. But after thinking again about it, I think this is better done with a life cycle policy rather than in this code base.

Beside that, there was nothing I was intending to implement. The smaller the code base stays, the better.

[erdi]

I can report back that we've been using this plugin on one of our projects for over a month now. It was straightforward to set up by following the instructions and using standard way of providing AWS credentials and it does a really good job for us. It's a great feeling when you locally build a revision which was previously built on CI and the build is blazingly fast because all the outputs are resolved from the cache.

The only very minor issue we have is that it uses a version range for the compile dependency on com.amazonaws:aws-java-sdk-s3. This leads to unnecessary trips to maven repo to check if new version is available (albeit at most every 24 hours if you have default dynamic version configuration, but still) and can lead to non-reproducible builds. It's quite easy to fix the version using a snippet like this in your settings.gradle file:

buildscript {
    configurations.classpath {
        resolutionStrategy.eachDependency { details ->
            def requested = details.requested
            if (requested.module.toString() == "com.amazonaws:aws-java-sdk-s3" && requested.version == "1.+") {
                details.useVersion "1.11.539"
            }
        }
    }
}

but I would still argue that this version should not be dynamic by default. I'm happy to create an issue and a PR for making the version static if you'd be willing to accept them, @myniva.

[myniva]

Thank you @erdi for the comprehensive feedback, much appreciated!

I would be happy to accept a pull request which is addressing the issue regarding the version of the AWS S3 SDK.

[erdi]

Cool, you can expect a PR sent your way soon.

[bsideup]

FYI we successfully migrated to DigitalOcean thanks to #8:
testcontainers/testcontainers-java@64dcf7a