How to build a plugin on a public hosted Continuous Integration server?

Hi there,

we'd like to be able to build the Randori plugin using a hosted CI service (like http://www.cloudbees.com/foss/index.cb for instance).

Generating the ANT scripts etc isn't much of a problem of course, but right now, I'm not entirely clear on the SDK location.

Our code resides in a public repository at github, which gets checked out by the CI server. Yet, how do we reference
the SDK? I don't suppose the required jars are deployed to, for example, a Maven repository?
I'd like to know the recommended configuration for this.

Has anyone any experience with this particular scenario?

Thank you very much for your time,

cheers,

Roland

4 comments

No, IntelliJ IDEA is not available in any Maven repository. If you only need Community Edition jars, you can simply put them into your VCS repository.

0

Aha, that is too bad, we are using jars of the Ultimate edition as well. (JavaScript, Flex and such).

So, in this case it means, I guess, that we can't go this route.

Thanks for the info!

cheers,

Roland

0

I don't know that this will help you - but this is the system I am using. My build server is private - but only because I don't have anywhere to host it that wouldn't just be more of a hassle.

I created (In TeamCity) agent properties for each version of the SDK.

system.teamcity.idea10.home=D\:\\idea10
system.teamcity.idea11.home=D\:\\idea11
system.teamcity.idea12.home=D\:\\idea12
system.teamcity.idea12.1.home=D\:\\idea12.1
system.teamcity.storm.home=D\:\\webstormß



I used NT Junctions/symlinks to always have idea10 point to the version 10 SDK I had installed. So I only set these up once in TeamCity.


This was actually very useful since my build agents could tell the build server what platforms they were capable of building, and I could use those properties to refer to the IDEA SDK in my build configurations and by doing so I created a requirement that an agent expose the property if it had the SDK installed. So there was never an issue knowing who could build what.

Next I manually updated the <idea-version since-build="130.0000" until-build="130.9999"/>
in each branch of the plugin.xml for the various platforms, and I maintained this so that it built plugins only for the specific range of versions of the SDK the build configuration supported. So this way the plugins that were built only worked for the SDK's they supported, and they would be disabled in intelliJ if a version was released that I had not yet tested against.. This was probably sub-optimal, but you don't want the SDK to change automatically - well I didn't.

You could also just get the version from the build.txt that is in each IntelliJ installation folder.

This system is not elegant - but it gets the job done. It also tags and releases builds and other nice things that CI servers do.

In theory you could just doenload the zip's of the IDEA releases, and use those as your jars. See: http://download.jetbrains.com/idea/ideaIU-12.0.4.zip

You can use them for the JAR files only - assuming its ok with the JetBrains guys.

I leave that one up to you. Personally I like knowing that the IDEA SDK will remain constant until I have a chance to try it out myself.
0

Hey Jon,

this was pretty much what I had in mind as well, but thanks for posting your setup, its always great to have something to start off on.

cheers!

Roland

0

Please sign in to leave a comment.