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.
> 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 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.
> - 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
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
> (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.
> 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/
> 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 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/CA%2BnPnMwr6eTNZoEn6tiyi5peuZgWrQeH21s_%3DtYw-PO9qiKJOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
