Lucene - Core
  1. Lucene - Core
  2. LUCENE-4949

nightly builds have wrong version - need to simplify jenkins config tweaks needed after a release

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.3.1, 5.0
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Right now, if you look at the configuration for these two apache jenkins jobs...

      ..you can see that even though they are building off of the 4.x branch, and even though the 4.x branch says the next version is 4.4, the artifacts from these jobs are labeled as if they will be 4.1 releases.

      1. LUCENE-4949.patch
        2 kB
        Uwe Schindler
      2. LUCENE-4949.patch
        2 kB
        Uwe Schindler

        Activity

        Hide
        Shalin Shekhar Mangar added a comment -

        Bulk closing after 4.3.1 release

        Show
        Shalin Shekhar Mangar added a comment - Bulk closing after 4.3.1 release
        Hide
        Shalin Shekhar Mangar added a comment -

        Back ported to 4.3.1 r1483404.

        Show
        Shalin Shekhar Mangar added a comment - Back ported to 4.3.1 r1483404.
        Hide
        Steve Rowe added a comment -

        If there are no objections, I'd like to backport this to 4.3.1.

        Show
        Steve Rowe added a comment - If there are no objections, I'd like to backport this to 4.3.1.
        Hide
        Uwe Schindler added a comment -

        Committed. I will now change the jenkins configs for artifacts (4.x and trunk)

        Show
        Uwe Schindler added a comment - Committed. I will now change the jenkins configs for artifacts (4.x and trunk)
        Hide
        Commit Tag Bot added a comment -

        [branch_4x commit] uschindler
        http://svn.apache.org/viewvc?view=revision&revision=1470978

        Merged revision(s) 1470975 from lucene/dev/trunk:
        LUCENE-4949: Make the version prefix ("SNAPSHOT") separately configurable to enable Jenkins use its BUILD_ID variable, cleanup code duplication

        Show
        Commit Tag Bot added a comment - [branch_4x commit] uschindler http://svn.apache.org/viewvc?view=revision&revision=1470978 Merged revision(s) 1470975 from lucene/dev/trunk: LUCENE-4949 : Make the version prefix ("SNAPSHOT") separately configurable to enable Jenkins use its BUILD_ID variable, cleanup code duplication
        Hide
        Commit Tag Bot added a comment -

        [trunk commit] uschindler
        http://svn.apache.org/viewvc?view=revision&revision=1470975

        LUCENE-4949: Make the version prefix ("SNAPSHOT") separately configurable to enable Jenkins use its BUILD_ID variable, cleanup code duplication

        Show
        Commit Tag Bot added a comment - [trunk commit] uschindler http://svn.apache.org/viewvc?view=revision&revision=1470975 LUCENE-4949 : Make the version prefix ("SNAPSHOT") separately configurable to enable Jenkins use its BUILD_ID variable, cleanup code duplication
        Hide
        Steve Rowe added a comment -

        +1, thanks Uwe

        Show
        Steve Rowe added a comment - +1, thanks Uwe
        Hide
        Uwe Schindler added a comment -

        Small update in the regular expression to make the solr parent module work correctly with file name naming (src.tgz and tgz files).

        Show
        Uwe Schindler added a comment - Small update in the regular expression to make the solr parent module work correctly with file name naming (src.tgz and tgz files).
        Hide
        Uwe Schindler added a comment - - edited

        Here is a patch that creates the $version property out of multiple components. In Jenkins, we would simply pass

        -Ddev.version.suffix=${BUILD_ID}

        This would override "SNAPSHOT".

        I also fixed duplication in Solr's common-build, we no longer need to define version numbers inside solr, the Lucene part creates the full version, the full JAR file name (including the special case for solr, where no lucene- is prepended to file name).

        Show
        Uwe Schindler added a comment - - edited Here is a patch that creates the $version property out of multiple components. In Jenkins, we would simply pass -Ddev.version.suffix=${BUILD_ID} This would override "SNAPSHOT". I also fixed duplication in Solr's common-build, we no longer need to define version numbers inside solr, the Lucene part creates the full version, the full JAR file name (including the special case for solr, where no lucene- is prepended to file name).
        Hide
        Uwe Schindler added a comment -

        I will take care tomorrow on changint the suffix. The default would be "SNAPSHOT". If you want to override the whole version, you can do this as usual.

        Show
        Uwe Schindler added a comment - I will take care tomorrow on changint the suffix. The default would be "SNAPSHOT". If you want to override the whole version, you can do this as usual.
        Hide
        Uwe Schindler added a comment -

        I fixed the Jenkins Jobs.

        Show
        Uwe Schindler added a comment - I fixed the Jenkins Jobs.
        Hide
        Hoss Man added a comment -

        If you look at the config for the apache jenkins 4x jobs, you can see that problem comes from how the jobs are configured to include hte jenkins build identife in the version info.

        they have the following env variable set...

        VERSION=4.1-${BUILD_ID}
        

        ...which is then used by the ant target via a command line sys prop like so...

        version=$VERSION
        

        Which means...

        1) all nightly 4.x builds have been claiming that they are "4.1-*" nightly builds (example "solr-4.1-2013-04-22_10-31-16.tgz") for a long time
        2) that this jenkins instance (and any similar jenkins or other continuous build instances) that want to create automated snapshot builds from a lucene/solr branch need to have their config updated anytime the version number changes on that branch otherwise they are lying.

        Proposal...

        We should introduce some simple, optional, "version.suffix" type property that can be used automated build systems like jenkins to easily set the build date or build number or whatever as a part of the version number, relying on the info on the branch to set the dominate pieces of hte version, so that a jenkins config could simply run something like...

        ant -Dversion.suffix="-${BUILD_ID}" prepare-release-no-sign 
        

        ...and never need to change as new releases are generated off this branch.

        (We could even consider setting this property up so that it included the jenkins BUILD_ID by default, not sure if anyone cares about that though)

        Show
        Hoss Man added a comment - If you look at the config for the apache jenkins 4x jobs, you can see that problem comes from how the jobs are configured to include hte jenkins build identife in the version info. they have the following env variable set... VERSION=4.1-${BUILD_ID} ...which is then used by the ant target via a command line sys prop like so... version=$VERSION Which means... 1) all nightly 4.x builds have been claiming that they are "4.1-*" nightly builds (example "solr-4.1-2013-04-22_10-31-16.tgz") for a long time 2) that this jenkins instance (and any similar jenkins or other continuous build instances) that want to create automated snapshot builds from a lucene/solr branch need to have their config updated anytime the version number changes on that branch otherwise they are lying. Proposal... We should introduce some simple, optional, "version.suffix" type property that can be used automated build systems like jenkins to easily set the build date or build number or whatever as a part of the version number, relying on the info on the branch to set the dominate pieces of hte version, so that a jenkins config could simply run something like... ant -Dversion.suffix="-${BUILD_ID}" prepare-release-no-sign ...and never need to change as new releases are generated off this branch. (We could even consider setting this property up so that it included the jenkins BUILD_ID by default, not sure if anyone cares about that though)

          People

          • Assignee:
            Uwe Schindler
            Reporter:
            Hoss Man
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development