On 25/06/2011, at 9:13 PM, Hans Dockter wrote: > I thought it would be helpful for our users (and for ourselves) to turn our > manual dists and docs CI build into a nightly build so that once a day: > > - The latest doc is uploaded to the website > - The latest binaries are Upload the snapshot binaries/dists to our repo
I wonder if we should trigger this more regularly, either: - on every commit, as part of a 'slow but complete coverage' CI build that runs in parallel to a 'fast but limited coverage' CI build, or - on every successful CI build. > > I did the following changes to achieve this: > > - Define a nightly trigger for the CI docs & dists build > - Before my changes the wrapper is using the latest dist from the > distributions/gradle-snapshots repo. Those snapshots are handpicked and we > have to keep them for historical builds. That is the reason why we don't > upload daily. > > First, for consistency with the general repo naming schema we have, I have > added a distinct distributions-snapshots repo instead of a gradle-snapshots > subdirectory in the distributions repo. For backwards compatibility we leave > the current distributions/gradle-snapshots untouched but shouldn't use it > anymore. I have added another repo called wrapper-snapshots. One thing to note is that the wrapper task uses 'distributions/gradle-snapshots' as the default location for downloading non-release distributions, as does the tooling api when you use GradleConnector.useGradleVersion(someVersion). What this change would mean is that when you use an older version of Gradle (ie pre 1.0-milestone-4) to generate your wrapper properties to use a new snapshot of Gradle, it will won't be able to find the binaries. It won't break if you're editing your wrapper properties file by hand and you happen to know the new location for snapshots. Given that we went through this pain for the 0.9 move from dists.codehaus.org to repo.gradle.org only 6 months or so ago, I'd rather not move the snapshots again, as I can't really see any benefit we get from using 'wrapper-snapshots' instead of 'distributions/gradle-snapshots'. On the other hand, there might be some artifactory magic we can use to map anything published to 'distributions/gradle-snapshots' so that it also appears in 'wrapper-snapshots'. In which case, the move might be fine to do. If we do move the 'permanent' snapshots to a new location, I'd rather call it 'distribution-snapshots' rather than 'wrapper-snapshots', and call the repo containing the temporary snapshots something which reflects the fact that they may disappear at any time. > The repo distributions-snapshots is used for uploading the nightly dists. If > we want to use a certain snapshot for our wrapper build we can go to > Artifactory, select the snapshot, click copy and specify wrapper-snapshots as > the destination. I would like to define a cleaning strategy for > distributions-snapshots (e.g. everything older than 30 days) but don't know > how to do this yet. > > We might also write a task that copies the latest from > distributions-snapshots into wrapper-snapshots. What's interesting about this, is that this is the start of a build pipeline, which might go something like this: - The CI build publishes candidate binaries to some staging repo. - We occasionally choose one of these to promote to 'snapshot' status, and manually run the appropriate teamcity build. This build could run some smoke tests, and move the binaries to the 'snapshots' repo. These are now available for anyone to use, and will never be deleted. We could set up something similar for releases. It certainly would be nice if most of the work of building, testing, and publishing to some staging area has already been done by the build server when we go to do a release. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
