I am in the process of implementing Jenkins as a continuous integration system at work. It’s an incredibly extendable framework so just perfect for our needs.
We will be keeping things simple to begin with: Simply grabbing appropriately tagged code from Subversion and making it available for installation elsewhere. It will be handling multiple projects which will solve a current issue with each project having its own secret sauce build system. Centralisation is good!
However, I did encounter an issue with symbolic links. We had a few instances where the symbolic link referenced a location outside of the repository, which would not exist on the build server. Jenkins does not preserve symbolic links when archiving. Instead, it tries copying them… and in this example that results in an error.
The solution I have gone for is to:
- Get rid of those symbolic links where possible.
- Convert to relative links in the case where absolute links were making a repository not compatible with a neutral build server.
This works nicely.
I have received some advice on StackOverflow on this issue which has been useful. In particular, an alternative archiving system (such as tar) could preserve the symbolic links, although would need to be implemented at a build level.
In terms of a final installation package for the projects, we are going down the RPM route here, which looks like a happy medium. I don’t mind Jenkins effectively dereferencing symbolic links for installations: Permissions and the like are what we need to watch out for!