2017-10-20 11:50 GMT+03:00 Stephen Connolly <[email protected] >:
> On 19 October 2017 at 17:42, Kanstantsin Shautsou < > [email protected]> wrote: > >> Trying to make multibranch support with not messed buildhistory by >> reusing my flexible github triggering code and experience. >> > > Unclear what you mean by "not messed build history"... with multibranch, > each branch gets its own clean history... the only issue that I know about > build history is that when a new branch is discovered, its first build will > have an empty history (we'd like to have it link to the other branch that > this new branch was forked from... though that may not always be possible) > > Or are you referring to the crazy of having git build many branches of in > a single job that drove me to develop multibranch in the first place. > Yes, i mean that it good to have separated history. > > >> Have some questions after first scm/branch/freestyle API reading >> impression: >> - Why uncategorized view is primary >> jenkins.branch.MultiBranchProjectViewHolder#getViews >> and how to set own primary view? >> > > Because the "standard" SCMHeads should not have a category. > Why? > > >> - Why uncategorized DEFAULT view (category) is named "Branch" by default? >> > > That is a decision for the SCMSource. If Accurev gets around to > implementing SCM API then that would probably have its uncategorised > category called `Stream` > > If you then have a multibranch project with two sources, one github and > the other accurev then you would have: > > - `Branches / Streams` as the default view > - `Snapshots / Tags` if somebody has enabled tag discovery on both > SCMSources > - `Pull Requests` if you enable pull request discovery for GitHub but > there is no equivalent category for accurev... if accurev had an equivalent > functionality and it was enabled at the same time then you'd have this tab > called `Change Requests / Pull Requests` (in the event that Accurev uses > the term `Change Requests`... if they use the term `Pull Requests` then > this would be just `Pull Requests` as both sources would be agreeing on the > terminology. > AFAIR they will be in one view only when they will have one category that sounds weird to mix different sources in one view. > > >> - Freestyle-multibranch uses observer jenkins.branch.MultiB >> ranchProject.SCMHeadObserverImpl#observe is it possible to replace it >> with custom logic? >> > > Why should it do custom logic? It's job is just to create the project and > trigger a build if and only if: > > 1. The SCMRevision is different from the previous > That wrong assumption locked all APIs to only this one possible thing in triggering branch/pr builds. Though i can try to hack it and control build triggering via it in deterministics and equals. 2. The BranchBuildStrategy gives the OK to build (or if there are no branch > build strategies then auto-build everything except tags) > > >> This observer is not flexible and not extendable, it can do only simple >> case comparison this vs that by revision. How to run the same build if it >> was already built? Revision+Head are not enough information. >> > > BranchBuildStrategy is the place for more complex decisions, multibranch > is opinionated and aims to remove the effect of 100 jobs trying to poll for > changes and replace that with (worst case) one multibranch polling for > changes or (best case) one multibranch being pushed events > Where did you saw 100 jobs targeted to one repository for 100 branches? Before people used one trigger that produced messed build history with different branches/prs in one job, but trigger was one, now the same. > > >> (Probably this is an answer why there is still no smart messages for >> rebuilds. >> if (rebuild) { >> >> listener.getLogger().format( >> >> "%s reopened: %s (%s)%n",) < why API expects defined >> behavior? Again, what if i want rebuild by comment, date, other ifluence? >> > > Freestyle-multibranch was an early experiment, probably needs some > updating to the latest code. > This code is from fresh branch api observer. > > >> One more place of decision making is SCMSourceCriteria... Oh, and >> Trait(?)... And BranchPropertyStrategy... How much places are designed for >> decision making and influence on final result? >> > > The SCMSourceCriteria is to decide *is this a branch/tag/pr that should > have a project created* > > The BranchPropertyStrategy is to decorate each child job > > The BranchBuildStrategy is to decide when to build branches > > >> Can i decide in one (my) place and just return to multibranch my >> decision: "this head, branch, etc should be built, please create views by >> corresponding SCMHeadCategory, etc" Or just not call observe and bypass it? >> > > The Multibranch is supposed to create one view for each of the > (consolidated) categories that its SCMSources report are enabled. If you > don't like that then you can override `newFolderViewHolder` and return your > own view holder. Keep in mind that in an Org Folder the user will not be > able to configure the views for each repository, so the view holder must be > automatic. > > >> - Is State.class expected to be used as persistent storage of data for >> plugins? If yes, then how to control exceptions during xmlread to exclude >> data clearing? >> > > It is intended to store the SCM-API state in order to allow the branch-api > to decide when to trigger rebuilds, etc > >> -- >> 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 [email protected]. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/jenkinsci-dev/5e646943-4151-4084-9f92-89788467a5ae%40googlegroups.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/5e646943-4151-4084-9f92-89788467a5ae%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 a topic in the > Google Groups "Jenkins Developers" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/jenkinsci-dev/gEH1EdzMblM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/jenkinsci-dev/CA%2BnPnMwr6eTNZoEn6tiyi5peuZgWrQ > eH21s_%3DtYw-PO9qiKJOA%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwr6eTNZoEn6tiyi5peuZgWrQeH21s_%3DtYw-PO9qiKJOA%40mail.gmail.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAM9nkw9u%3DzJBm%3DCuH-4m8jEyd%2BNO8mgf0H1%3D%3DsNr0Dun5vpvHw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
