Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-30076

Build only latest of matched tags or branches

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin

      We use Jenkins to deploy project by building from the latest tag. To do so without a need to manually specify latest tag we use
      Refspec: +refs/tags/prod/:refs/remotes/origin/tags/prod/
      Branch specifier: /tags/prod/

      This works fine except for first time after git configuration fro project was changed, as it will try to build all unseen branches (in this case tags). It would be useful to have an option to build only latest tag or branch that matches ref spec and specifier. Or to be able to set branch specifier to executable script, for example

      git describe --tags `git rev-list --tags --max-count=1`
      

          [JENKINS-30076] Build only latest of matched tags or branches

          Mark Waite added a comment -

          Have you considered using the "Ancestry build chooser" under the "Strategy for choosing what to build"? It will let you choose to only build things within a time period, or only things which include a specific SHA1 in their history.

          Mark Waite added a comment - Have you considered using the "Ancestry build chooser" under the "Strategy for choosing what to build"? It will let you choose to only build things within a time period, or only things which include a specific SHA1 in their history.

          Nick Abalov added a comment -

          Yes, I have considered it. But the thing is we have unstable timeframes between releases. Sometimes one of the projects might go unreleased for a month, yet next month it will be released every week. I would like to be able to reliable setup git cloning in such way, so that it explicitly states that latest (release) tag should be built and there wont be any problem with plugin trying to rebuild all tags if we had to change remote url or something. "Ancestry build chooser" wont give me a reliable way.

          I think, it would be useful if there was "Last" strategy in "Strategy for choosing what to build" alongside with Ancestry and Inverse.

          Nick Abalov added a comment - Yes, I have considered it. But the thing is we have unstable timeframes between releases. Sometimes one of the projects might go unreleased for a month, yet next month it will be released every week. I would like to be able to reliable setup git cloning in such way, so that it explicitly states that latest (release) tag should be built and there wont be any problem with plugin trying to rebuild all tags if we had to change remote url or something. "Ancestry build chooser" wont give me a reliable way. I think, it would be useful if there was "Last" strategy in "Strategy for choosing what to build" alongside with Ancestry and Inverse.

          Mark Waite added a comment -

          I'm not sure I understand how the plugin would interpret the meaning of "Last" as a strategy. Are you thinking that the list of all matching tags would be generated, then the commit date of the matching SHA1's would be used to sort for the most recently applied SHA1?

          Or, would "Last" somehow be intended to mean the most recently applied tag, rather than the most recently applied commit?

          Mark Waite added a comment - I'm not sure I understand how the plugin would interpret the meaning of "Last" as a strategy. Are you thinking that the list of all matching tags would be generated, then the commit date of the matching SHA1's would be used to sort for the most recently applied SHA1? Or, would "Last" somehow be intended to mean the most recently applied tag, rather than the most recently applied commit?

          Nick Abalov added a comment - - edited

          I think there should be no difference between most recently applied tag or commit date in most cases, as release tags are usually applied in linear fashion.

          A--->B--->C--->D--->E
          v1                  v2
          

          If one wants to release a version of code that rollbacks to commit C that was made before previous release tag (v2), then one should make new commit, say F, that reverts functionality, instead of adding new version "v3" tag before "v2" tag.

          A--->B--->C--->D--->E--->F (revert to C)
          v1                  v2   v3
          

          So, for "Last" it can work by getting commit or tag date, which one is easier to implement.

          If you think that "Last" behaviour is ambiguous, "Semantic Latest" can be introduced for tags only. "Semantic Latest" can compare tag names following semantic versioning rules. Something along the lines:

          1. Stripping any prefix of tag name (v1.1.1 -> 1.1.1, prod/1.1.1 -> 1.1.1)
          2. Stripping any postfix of tag name (1.1.1-beta -> 1.1.1)
          3. Splitting rest of the name by dot (1.1.1 -> [1,1,1])
          4. Comparing lists semantic versioning rule
          5. If results of comparing version lists is ambiguous, then prefix and postfix should be compared as strings

          Nick Abalov added a comment - - edited I think there should be no difference between most recently applied tag or commit date in most cases, as release tags are usually applied in linear fashion. A--->B--->C--->D--->E v1 v2 If one wants to release a version of code that rollbacks to commit C that was made before previous release tag (v2), then one should make new commit, say F, that reverts functionality, instead of adding new version "v3" tag before "v2" tag. A--->B--->C--->D--->E--->F (revert to C) v1 v2 v3 So, for "Last" it can work by getting commit or tag date, which one is easier to implement. If you think that "Last" behaviour is ambiguous, "Semantic Latest" can be introduced for tags only. "Semantic Latest" can compare tag names following semantic versioning rules. Something along the lines: Stripping any prefix of tag name (v1.1.1 -> 1.1.1, prod/1.1.1 -> 1.1.1) Stripping any postfix of tag name (1.1.1-beta -> 1.1.1) Splitting rest of the name by dot (1.1.1 -> [1,1,1] ) Comparing lists semantic versioning rule If results of comparing version lists is ambiguous, then prefix and postfix should be compared as strings

          I recently also needed such functionality and didn't find what I needed:
          Example git repository: https://git.eclipse.org/c/platform/eclipse.platform.swt.git/log/?h=R4_4_maintenance I need a way to build the latest /^R(_\d*)+$/ tag.
          For now I manually trigger the build based on the branch, but that is not ideal obviously.

          Tag date and tagged commit date are definitely not ideal as tagging of a release commit may have been forgotten and added back later possibly after tagging more recent releases, however dates aren't really useful either because a project that has multiple supported versions may tag a 1.0.5 release and an 2.1.3 release, then a 2.1.4 and then a 1.0.6 where only the 2.1.4 would be interesting.

          So tag selection should support:
          1) first reached tag matching regex on specific branch.
          2) and latest tag based on http://semver.org/ (in the example given above v1.1.1 and 1.1.1-beta can't be distinguished properly whereas using semver they can)

          Ing. Christoph Obexer added a comment - I recently also needed such functionality and didn't find what I needed: Example git repository: https://git.eclipse.org/c/platform/eclipse.platform.swt.git/log/?h=R4_4_maintenance I need a way to build the latest /^R(_\d*)+$/ tag. For now I manually trigger the build based on the branch, but that is not ideal obviously. Tag date and tagged commit date are definitely not ideal as tagging of a release commit may have been forgotten and added back later possibly after tagging more recent releases, however dates aren't really useful either because a project that has multiple supported versions may tag a 1.0.5 release and an 2.1.3 release, then a 2.1.4 and then a 1.0.6 where only the 2.1.4 would be interesting. So tag selection should support: 1) first reached tag matching regex on specific branch. 2) and latest tag based on http://semver.org/ (in the example given above v1.1.1 and 1.1.1-beta can't be distinguished properly whereas using semver they can)

          Hi 

          I had created a jenkins job with Branch Specifier as :^(?!origin/master$).*.  I want to get jenkins build trigger when some one creates a private branch from master .  My Github repository have many private branches . When ever some developer creates a new private branch , jenkins start building from all old branches . Its very annoying as already build is created from those builds from other jenkins job . I wish to build build only from latest branches 

          Is there any way to trigger builds from latest branches . 

          Subhajit Dutta added a comment - Hi  I had created a jenkins job with Branch Specifier as :^(?!origin/master$).*.  I want to get jenkins build trigger when some one creates a private branch from master .  My Github repository have many private branches . When ever some developer creates a new private branch , jenkins start building from all old branches . Its very annoying as already build is created from those builds from other jenkins job . I wish to build build only from latest branches  Is there any way to trigger builds from latest branches . 

          Mark Waite added a comment -

          subhajit_dutta asking a question in a bug report will make your question visible to far fewer people than if you ask your question in one of the chat channels or on the users mailing list.

          Mark Waite added a comment - subhajit_dutta asking a question in a bug report will make your question visible to far fewer people than if you ask your question in one of the chat channels or on the users mailing list .

            Unassigned Unassigned
            nickab Nick Abalov
            Votes:
            4 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: