[jira] [Updated] (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

["Uwe Schindler (Updated) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler updated INFRA-4521:
---------------------------------

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

  was:
Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apachje.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). 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

    
> 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