On Fri 21 Apr 2017 at 22:57, Martin d'Anjou <[email protected]> wrote:
> Disclaimer: I do not use those plugins. > > > *Can you suggest a better UI name for this trait than "Discover branches"?* > > > No. > >> >> *Does "Discover branches" scream out what it does?* > > > Yes. > > >> >> *Can you suggest a better UI name for the "Strategy" field in "Discover >> branches"?* > > > No. > >> >> - *Can you suggest better names for any of the 3 strategy options?* >> >> Anything that contains something resembling a double negative confuses > me, e.g. "only that are not also", so if I understand correctly the types > of branches that may exist, this is my suggestion: > * Only PR branches > * Only non-PR branches > * All branches > > >> - Currently the GitHub Branch Source has two check boxes to control >> both whether it discovers pull requests originating from the repository >> itself and how to build those pull requests. >> >> I have replaced these two checkboxes with a trait. The trait has a >> drop-down configuration. Selecting either the 1st or the 2nd of these >> options will build either the merge or the head commit and will call the >> branches PR-xxx. Selecting the 3rd of these options will build two >> branches >> for every PR one called PR-xxx-merge and one called PR-xxx-head. >> >> *Can you suggest a better UI name for this trait than "Discover pull >> requests from origin"?* >> *Does "Discover pull requests from origin" scream out what it does?* >> *Can you suggest a better UI name for the "Strategy" field in >> "Discover pull requests from origin"?* >> *Can you suggest better names for any of the 3 strategy options?* >> >> >> Ditto and: > In BitBucket Server, pull-requests exist on the upstream, not on the > origin. But what does "origin" refer to here? > In terms of better names for the strategies: > * Checkout target branch and merge pull-request to it > * Checkout pull-request > * Do both (in separate builds) - (this is my understanding and I could be > wrong) > Not just separate builds, separate jobs. One job for PR-head and one job for PR-merge > > >> >> - *Can you suggest a better UI name for this trait than "Discover >> pull requests from forks"?* >> *Does "Discover pull requests from forks" scream out what it does?* >> *Can you suggest a better UI name for the "Strategy" field in >> "Discover pull requests from forks"?* >> *Can you suggest better names for any of the 3 strategy options?* >> >> Ditto. > > But now I am confused. Pull-requests in BitBucket Server have 4 > coordinates: source repo, source branch, target repo and target branch. > This results in the target branch being created on the target repo. And the > target repo is the only place where the pull-request can be discovered, as > far I as I know. So I am not sure what "discovering pull-requests on forks" > means vs. "discover pull requests from origin". > So this is discovering PRs where the source repo != target repo > > To me, a Jenkins Job should have a single purpose, and to me a single > purpose is to merge a pull request to a single possible destination. If the > Jenkins Job is able to merge to different destinations, then it's not the > same Job because it does not serve the same purpose. > Each "head" gets their own Job > > >> - *Can you suggest a better UI name for the "Trust" field in >> "Discover pull requests from forks"?* >> *Can you suggest better names for any of the current base default 3 >> strategy options: "Collaborators", "None" and "Everyone"?* >> >> Who is the list of collaborators and how does someone get there? > None -> Nobody? > > >> >> - Currently, hidden in the advanced box there is an Includes/Excludes >> option. There are a lot of requests for different syntaxes of specifying >> includes / excludes. Due to backwards compatibility we cannot change the >> syntax, so my solution is to allow plugins to extend and add traits for >> the >> different syntaxes. >> >> To retain backwards compatibility of existing configurations, we need >> to provide one that uses the current wildcard (without globs) matching. >> >> *Can you suggest a better UI name for this trait than "Filter by name >> (with wildcards)"?* >> >> What is being filtered by name? The name of the pull-request branch? The > name of the pull-request? > > Hope this helps, > Martin > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" 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-users/a6551467-5575-44f1-a0be-4ce644422668%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/a6551467-5575-44f1-a0be-4ce644422668%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Sent from my phone -- You received this message because you are subscribed to the Google Groups "Jenkins Users" 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-users/CA%2BnPnMy0LTi%3DE5F0PNMbSgEdFKM3iCwTetY67ud1BWUC-ZU%3D5w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
