Since no one else is fielding this question just yet, I'll go ahead. Ivy has three predefined statuses, where the status attribute appears /ivy-module/info in an ivy.xml file: integration milestone release
Even though Ivy in no way enforces this, the presumption is that the integration status represents snapshot or, well, integration versions—builds of a version that is still under development. The milestone and release statuses represent one-off builds. Once you build version 1.0-beta1 with milestone status, you aren't going to overwrite it with another 1.0-beta1 version, unless you do some kind of special in-house demotion. Once you build version 1.0.0 with release status, you're not going to produce another 1.0.0; the next release will be 1.0.1. The milestone and release modules should be built off tags in your SCM system. You're welcome to define your own statuses, but it's still advisable to make a sharp distinction between integration versions and non-integration versions. It's also advisable to bake the fact that we're talking an integration version into the the literal version and not just rely on status="integration". Sticking a suffix in the version, like 1.0-SNAPSHOT or 1.0-timestamp or 1.0-buildnumber (not unlike what Maven does), is the typical way to do this. There's a longer discussion about reproducible builds which I'll spare you. Now, suppose you have a release branch where you're preparing a release. You'd create a Jenkins job for this branch, and you'd make it publish to your enterprise artifact repository with status="integration". As you go along in the development of this branch, you'd weed out all the dependencies on integration (i.e. snapshot) versions of other modules. Then when you finally tag a milestone or release in source control, you would do a one-off build that publishes the Ivy module and its artifacts to the enterprise repository with status="milestone" or status="release" and the integration suffix stripped from the version string (revision="…" in the ivy.xml). Whether you create a Jenkins job to do this and do it from a shell shouldn't make a difference in terms of what gets published although at least with Jenkins you can take advantage of the reporting. At this point you should lock the job so that it doesn't build again (don't recall offhand how you do this). The job becomes effectively a historical document. Trying to capture some best practices here, but certainly Ivy will give you plenty of rope with which to hang yourself. On Thu, Dec 27, 2012 at 6:38 PM, Aris Green <[email protected]> wrote: > I have a manually scripted build process using MSBuild for compiling > and Ant + Ivy for publishing and sharing artifacts. The goal is to > move this in a Jenkins based CI system. I was wondering, how are > artifacts promoted from snapshots to let say, integration/release? I > have yet to find much on how this is actually accomplished. Do you > retrieve the artifacts from one branch into a local folder and publish > them to another. What are the "best practices". I am hoping to get > started in the right direction. > > Thanks > agreen >
