www-infrastructure-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (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 11:36:57 GMT

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

Uwe Schindler edited comment on INFRA-4521 at 3/7/12 11:36 AM:
---------------------------------------------------------------

I have a "good solution" to the problem:
I reinstalled the original binary FreeBSD package of subversion 1.7 from tb.apache.org, so
upgrades should work without conflicts or other problems.
Instead of compiling a static version of native SVN, I downloaded svnkit 1.7-beta3, extracted
it to the jenkins-tools folder and used our ANT coniguration to use the "CLI" versions of
svnkit to do the tasks. This works fine, as the jsvn and jsvnversion are compatible to the
originals. The cool thing is, that in contrast to original SVN, svnkit can handle all types
of checkout, so once Jenkins upgrades to later version of svnkit, the build still runs.

The last build was triggered like that:

/home/hudson/tools/ant/latest1.7/bin/ant -Dversion=4.0-2012-03-07_11-01-08 -Dsvnversion.exe=/home/hudson/tools/svn/svnkit/bin/jsvnversion
-Dsvn.exe=/home/hudson/tools/svn/svnkit/bin/jsvn clean package-tgz-src package-tgz

I think thats a good solution for now. My comment from earlier that we have to bundle svnkit
with our src repository is no longer valid, as we use the "emulated cli" from svnkit as replacement
to native svn.
                
      was (Author: thetaphi):
    I have a "good solution" to the problem:
I reinstalled the original binary FreeBSD package of subversion 1.7 from tb.apache.org, so
upgrades should work without conflicts or other problems.
Instead of compiling a static version of native SVN, I downloaded svnkit 1.7-beta3, extracted
it to the jenkins-tools folder and used our ANT coniguration to use the "CLI" versions of
svnkit to do the tasks. This works fine, as the jsvn and jsvnversion are compatible to the
originals. The cool thing is, that in contrast to original SVN, svnkit can handle all types
of checkout, so once Jenkins upgrades to later version of svnkit, the build still runs.

The last build was triggered like that:
{noformat}
/home/hudson/tools/ant/latest1.7/bin/ant -Dversion=4.0-2012-03-07_11-01-08 -Dsvnversion.exe=/home/hudson/tools/svn/svnkit/bin/jsvnversion
-Dsvn.exe=/home/hudson/tools/svn/svnkit/bin/jsvn clean package-tgz-src package-tgz
{noformat}

I think thats a good solution for now. My comment from earlier that we have to bundle svnkit
with our build is no longer valid, as we use the "emulated cli" from svnkit as replacement
to native svn.
                  
> 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
FreeBSD

--
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

        

Mime
View raw message