[JIRA] [git-plugin] (JENKINS-30076) Build only latest of matched tags or branches
Title: Message Title Nick Abalov commented on JENKINS-30076 Re: Build only latest of matched tags or branches 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. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-plugin] (JENKINS-30076) Build only latest of matched tags or branches
Title: Message Title
Nick Abalov edited a comment on JENKINS-30076
Re: Build only latest of matched tags or branches
Ithinkthereshouldbenodifferencebetweenmostrecentlyappliedtagorcommitdateinmostcases,asreleasetagsareusuallyappliedinlinearfashion.{code}A---B---C---D---Ev1v2{code}IfonewantstoreleaseaversionofcodethatrollbackstocommitCthatwasmadebeforepreviousreleasetag(v2),thenoneshouldmakenewcommit,sayF,thatrevertsfunctionality,insteadofaddingnewversionv3tagbeforev2tag.{code}A---B---C---D---E---F(reverttoC)v1v2v3{code}So,forLastitcanworkbygettingcommitortagdate,whichoneiseasiertoimplement.IfyouthinkthatLastbehaviourisambiguous,SemanticLatestcanbeintroducedfortagsonly.SemanticLatestcancomparetagnamesfollowingsemanticversioningrules.Somethingalongthelines:#Strippinganyprefixoftagname(v1.1.1-1.1.1,prod/1.1.1-1.1.1)#Strippinganypostfixoftagname(1.1.1-beta-1.1.1)#Splittingrestofthenamebydot(1.1.1-[1,1,1])#Comparinglistssemanticversioningrule#Ifresultsofcomparingversionlistsisambiguous,thenprefixandpostfixshouldbecomparedasstrings
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-plugin] (JENKINS-30076) Build only latest of matched tags or branches
Title: Message Title Nick Abalov commented on JENKINS-30076 Re: Build only latest of matched tags or branches 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 Add Comment
[JIRA] [git-plugin] (JENKINS-30076) Build only latest of matched tags or branches
Title: Message Title
Nick Abalov edited a comment on JENKINS-30076
Re: Build only latest of matched tags or branches
Ithinkthereshouldbenodifferencebetweenmostrecentlyappliedtagorcommitdateinmostcases,asreleasetagsareusuallyappliedinlinearfashion. {code} A---B---C---D---Ev1v2 {code} IfonewantstoreleaseaversionofcodethatrollbackstocommitCthatwasmadebeforepreviousreleasetag(v2),thenoneshouldmakenewcommit,sayF,thatrevertsfunctionality,insteadofaddingnewversionv3tagbeforev2tag. {code} A---B---C---D---E---F(reverttoC)v1v2v3 {code} So,forLastitcanworkbygettingcommitortagdate,whichoneiseasiertoimplement.IfyouthinkthatLastbehaviourisambiguous,SemanticLatestcanbeintroducedfortagsonly.SemanticLatestcancomparetagnamesfollowingsemanticversioningrules.Somethingalongthelines:#Strippinganyprefixoftagname(v1.1.1-1.1.1,prod/1.1.1-1.1.1)#Strippinganypostfixoftagname(1.1.1-beta-1.1.1)#Splittingrestofthenamebydot(1.1.1-[1,1,1])#Comparinglistssemanticversioningrule#Ifresultsofcomparingversionlistsisambiguous,thenprefixandpostfixshouldbecomparedasstrings
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-plugin] (JENKINS-30076) Build only latest of matched tags or branches
Title: Message Title Nick Abalov created an issue Jenkins / JENKINS-30076 Build only latest of matched tags or branches Issue Type: New Feature Assignee: Nicolas De Loof Components: git-plugin Created: 21/Aug/15 4:17 AM Labels: git plugin Priority: Minor Reporter: Nick Abalov 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`
