www-infrastructure-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Olivier Lamy (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (INFRA-4521) Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
Date Wed, 07 Mar 2012 09:16:57 GMT

    [ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224112#comment-13224112

Olivier Lamy commented on INFRA-4521:

NOTE for some license reason Jenkins doesn't and cannot include last svnkit version. The current
included svnkit is based on a fork before license changed. Maybe the workaround could be about
doing a new Jenkins plugin which include last svnkit for 1.7 but this cannot be included in
Jenkins distribution.
BTW Uwe what your build is doing ? parsing result of svn cli to get rev ? Could you simply
do it with svnkit previous version ?
> Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN
(1.7) on the upgraded FreeBSD slaves for some builds
> -----------------------------------------------------------------------------------------------------------------------------------------
>                 Key: INFRA-4521
>                 URL: https://issues.apache.org/jira/browse/INFRA-4521
>             Project: Infrastructure
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: Jenkins
>         Environment: FreeBSD 9 Jail, lucene.zones.apache.org
>            Reporter: Uwe Schindler
> Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used
as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection
was also upgraded and now uses Subversion 1.7 as default.
> The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN
client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless
the build script itsself uses subversion to detect e.g. the revision number to put it into
the manifest file of built jars (for that case we have a fallback: it only does this if it
suceeds, otherwise the version number is undefined). But in our case the revno is also needed
to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN
revision is mandatory, and failing to get them is a problem for our builds.
> The problem is simple: The SVN checkout our build is started from Jenkins is Subversion
1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn
checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout
version and nuke it, and re-checkout with 1.6.
> For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion
and installing /usr/ports/devel/subversion16.
> The points for discussion:
> - Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
> - If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
> - If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message