Doesn't look too bad in the default new-instance state: [image: Inline images 1]
I'll roll a new set of alpha's after I finish writing the migration tests On 23 June 2017 at 15:24, Joseph P <joseph...@gmail.com> wrote: > Adding discover branch trait makes a lot of sense when other traits will > join in. > So take the migration part now. > > And if your need more vertical space, just flip your monitor into > porTrait.. pun intended. :D > > > Den fredag den 23. juni 2017 kl. 15.29.20 UTC+2 skrev Stephen Connolly: >> >> So before we cut a GA release of the JENKINS-43507 changes I thought it >> might be a good idea to resolve one question. >> >> To understand the context of this, we first need to acknowledge >> https://issues.jenkins-ci.org/browse/JENKINS-33445 >> >> There are some users who would like the *Branch* source to also return >> *Tag*s >> >> Now in a sense this is perfectly reasonable. I think there are some >> things that need to be ironed out first before we can enable discovery of >> tags. To give an example, you probably do not want to trigger a build storm >> of all your old tags if you recreate the multibranch project... in fact if >> you were using the pipeline to deploy to production when it detects the >> build is on a tag... this would be a very bad plan. >> >> So before we enable the discovery of tags, we need to solve some >> problems... >> >> But now, let's take it as read that we have solved those problems... this >> means that the Git source could be configured into one of four possible >> states: >> >> 1. Stupid state: discovers nothing >> 2. Branches only >> 3. Tags only >> 4. Both branches and tags >> >> The natural way, given the conventions in the GitHub and Bitbucket >> behaviours / traits is that we would have one behaviour for discovering >> branches and one for discovering tags... >> >> Well right now GitSCMSource has neither, it just discovers branches >> always. >> >> That means we would have to grandfather in the discovery of branches. >> >> So if we read a GitSCMSource from disk and it has no discovery traits we >> would then assume it is not configured thus by the user intent on it being >> in the stupid state... rather they want to discover branches... the >> constructor would have to always add the discovery trait from the start and >> people would need to configure away branch discovery... it seems like a bit >> of a mess to me. >> >> So what I am thinking is that we just add a Git specific "Discover >> Branches" behaviour to the plugin before the 3.4.0 GA release. The legacy >> constructor would inject it as would readResolve and the UI would always >> propose it when creating via the UI >> >> It does mean that the UI will always start with Discover Branches present >> (taking up vertical space that is effectively useless until we get Discover >> Tags) but I think it will make the addition of Discover Tags much less risky >> >> WDYT? >> >> -Stephen >> > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jenkinsci-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/jenkinsci-dev/c76e7027-5bbc-42f4-9ee6-bc2fa1eed920% > 40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/c76e7027-5bbc-42f4-9ee6-bc2fa1eed920%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwX9c1N%3De2c15jT-ofn2GjS%3DRrr_w1N3OOL1GvifWF2NQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
