Join GitHub today
Automated e2e testing and pushing version upgrades to consumers #85
Above are the problems of the challenges of the producer-client lifecycle. Let's figure out a set of plugins an features that will streamline evolution and adoption of new versions.
Let's try to identify a scalable solution that can evolve into a general-purspose feature that allows convenient evolution of versions of OSS libraries. Below is the result of our internal discussions with @mstachniuk and @wwilk:
Suggested solution would scale because
To get started, let's get a single client local e2e test (example project) hooked up in the release-tools project. For version bumping, we can use Mockito's pattern of keeping the version of tools in gradle.properties file.
In future this could potentially turn into more general capability we would add to release tools. It would be great if clients of release automation could automatically validate if their changes work with selected open source projects on GitHub. For example, I would love if every change of Mockito was tested with some other GitHub projects like guava. This potentially can be extremely useful feature.
It sounds great! It's a huge. Let's maybe starts from something simpler.
@szpak, we share the vision, now it's time to start working together :) Join us and we'll be unstoppable! 4 of us cranking great release automation toolkit!!!
https://github.com/Codearte/gradle-nexus-staging-plugin is a great plugin. We could merge our efforts :)
Sounds great! We'll have more example projects, for different use cases (for example: minimal configuration, based on defaults VS full configuration; with notable releases VS without notable releases; with bintray VS with just maven central). So it would be good if the impl was generic enough to handle more 'test' projects in the future :D
changed the title
Automated validation of clients and version evolution of producers
Apr 28, 2017
This was referenced
May 4, 2017
For testing purposes you need to apply E2E plugin in