On Sun, Jun 26, 2011 at 9:18 AM, Adam Murdoch <[email protected]>wrote:
> > 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'. > It violates the naming schema we use for all the other repositories in Artifactory online. No big deal but still something I would like to see fixed though. > 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. > I will ask the JFrog guys. > > 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. > I think it is common and expected behavior in repository land, that the *-snapshots repo has disappearing snapshots.I would like to reflect that in the name, by using the same name we use for our releases with a snapshots postfix. The repo with the permanent snapshots has so far only one use case, to support our own Gradle build, which is completely internal. Some people might also use it for their wrapper build, but I think we should limit the use cases where we upload special snapshots there for other projects. We could give wrapper-snapshots a different name though. For example distributions-permanent-snapshots. Picking up your idea from below, we could call it something like distributions-milestones. > > > 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. > Sounds kind of like milestone releases. In any case, I think that promotion should go together with a name change (be it milestone or an additional postfix we add to the timestamp). We might not use the term snapshot for those. > > 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. > I like the idea very much of seeing this as our deployment pipeline. Hans > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > >
