On Friday, October 20, 2017 at 2:16:41 PM UTC+3, Stephen Connolly wrote: > > > > On 20 October 2017 at 04:02, Kanstantsin Shautsou <[email protected] > <javascript:>> wrote: > >> >> >> 2017-10-20 11:50 GMT+03:00 Stephen Connolly <[email protected] >> <javascript:>>: >> >>> On 19 October 2017 at 17:42, Kanstantsin Shautsou <[email protected] >>> <javascript:>> 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? >> > > because categories are a mix-in. Some SCMs will not have different types > of "branch like" things that can be discovered. > > >> >>> >>> >>>> - 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. >> > > So the expected case is that you only ever have one SCMSource... but > consider the case where you are migrating from one SCM to another for your > "project" > > In that case you might have both Accurev and GitHub with the maintenance > branches on one and the new development on another. > > Now when I need to go look at the status of a "branch" (and as a developer > I don't give a f*ck whether the SCM called that a "Stream" or a "Branch") I > want to go to one tab and see all of them together... same goes for > tag/snapshot and pull request/change request. > > So we group the same categories together... categories are a way of > grouping outside of the class hierarchy > > >> >>> >>>> - Freestyle-multibranch uses >>>> observer jenkins.branch.MultiBranchProject.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. >> > > If you were to have multibranch just creating the jobs, you'd have 100 > jobs all doing polling for some SCMs... don't just think Git > > >> >>> >>>> (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. >> > > I had a multibranch freestyle impl that I pushed the code for... I didn't > do any more on it because of the UI config problem. > Could you remind what exactly? Something around descriptor and displayName?
> > >> >>> >>>> 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] <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/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] <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwr6eTNZoEn6tiyi5peuZgWrQeH21s_%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] <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/CAM9nkw9u%3DzJBm%3DCuH-4m8jEyd%2BNO8mgf0H1%3D%3DsNr0Dun5vpvHw%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/3766d647-49a9-4e39-bdde-841d19355cb5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
