Hey, On Fri, Dec 23, 2011 at 5:12 AM, cato1971 <[email protected]> wrote:
> I am looking to get involved in the Gradle community, am a user, advocate, > fan and share it through all the channels available to me. I do have a > passion for delivery (which was one of the reason Gradle appeals) but > having > just checked out the CI server have some questions to ask - and hope that I > am asking them in the correct place. > Glad to have you on board :) >From a deveoper viewpoint I find the Team City builds to lack what I would > expect. I have not used Team City so forgive me if it is a tool > capability/familiarity issue. When using Jenkins/Hudson in conjunction with > Sonar for trending I see trends, visual test status, visual violations etc. > I like to see groups of tests, module metrics to determine/maintain > internal > quality. It does not matter which tools, just that quality is maintained > and > measured - I am NOT for one moment questioning the quality of the code, am > just advocating its visualization. I could contribute here if people feel > it > would be worthwhile. > > As for the build pipeline - the whole Continuous Delivery relies to some > extent on limiting the time builds are in the red. I noticed that the > builds > on the CI take upwards of 50 minutes! Thats is a long time to wait for > feedback on a build - are there ways to break the build down into stages > that would provide faster feedback (or are the public CI builds merely the > final stage of such a pipeline?). > We are aware the builds are long, however I'm not really that much concerned about it. E.g. obviously I'd like the build to be fast but I understand the trade-off of having lots of integration tests. Majority of the build time is consumed by the integration tests and we are adding more and more of them as we add features or improve the coverage. Decomposing the build into smaller Team City jobs to form a pipeline wouldn't add much value to my workflow. Since I know what I'm working on I tend to run selective set of tests/checks before pushing to github and that is fast enough for me. Here're some things important that from my standpoint that are related to build refactoring/maintenance. 1. Refactor the build somehow so that integTests are better separated so that it's easier declare task dependencies precisely. E.g. some integ tests need samples extracted from docs, some integ tests need zipped distro, all integ tests need XXX. Currently all those prerequisites are lumped into a sequence of actions that must happen before any integTest runs. That's ineffective in development. 2. Measure/visualize the heap consumption for building a meaty multiproject with reasonable dependencies. We'd like to trend that and grow it into nice performance suite. 3. There're few integ tests that fail occasionally worth fixing properly so that they will pass all the time. 4. Make the gradle project itself importable to eclipse. This requires refactorings in the build. Introduce a test that will prevent breaking this feature. 5. I'm pretty sure jira contains some maintenance tasks (however looking them up might be somewhat a chore :) > Could some of the developers share there experiences of the Gradle build > pipeline and some of the complexities/issues it deals with - e.g need to be > tested on different OS's and Java VMs etc. Would they like to see some > improvements in the pipeline? Could I be of assistance in this process? Apart from that am keen to pick up some maintenance tasks if anyone has a > particular favourite for me to start with then point me in the right > direction. > Regarding the build pipeline or CI maintenance tasks I'm not sure how feasible it is to contribute because the contributor must be given access to our private servers/infrastructure. Therefore we'd probably prefer traditional contributions via github/pull request. We're tight on time and usually it's taking some time to review / refactor the pull request. That's why we prefer sweet and neat patches that have tests, documentation, nice code, etc :) Oh, and I'm speaking for myself so other team members might have a different view! Thanks a bunch for reaching out and sorry for quite a late response. You have started a big subject, though =) > > Cheers > Pete > > -- > View this message in context: > http://gradle.1045684.n5.nabble.com/The-Gradle-Build-Visualization-Pipeline-tp5096265p5096265.html > Sent from the gradle-dev mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
