Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-43507] Migrate Bitbucket Plugin to Traits #53

Merged
merged 44 commits into from
Jul 5, 2017

Conversation

stephenc
Copy link
Member

@stephenc stephenc commented Jun 12, 2017

See JENKINS-43507

Downstream of:

Will not be merged until after equivalent changes to GitHub plugin have been pushed to a pull-request

@reviewbybees

P.S. I have tried to be as careful as possible making the changes step by step in order to ensure that the behaviour of the code being refactored remains unmodified for anyone upgrading from an existing configuration from older versions of the plugin. Unfortunately this required a large diff of changes in the end. If it is any consolation to reviewers, I will also be re-reviewing all this code before I am happy to merge... yes it is a 12k LOC pull request

stephenc added 16 commits May 22, 2017 11:53
Also:

- Adds support for building the merge commits of pull requests
- Adds support for trusted revisions
- Adds support for configuring Git extensions and Mercurial additional behaviours
- Adds lots of tests (traits make code that was previously hard to test easier to test)

Should:

- Migrate existing configuration to the same effective configuration
- Maintain backwards binary compatibility
- Not maintain backwards source compatibility (if you wrote a plugin to the old APIs you will need to fix when you upgrade the plugin dependency)
@ghost
Copy link

ghost commented Jun 12, 2017

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

@stephenc
Copy link
Member Author

(build failure is just -SNAPSHOT dependency missing... will be fixed after I get the GitHub PR ready, if not before)

@stephenc
Copy link
Member Author

Code coverage before:
screen shot 2017-06-12 at 16 28 43

Code coverage after:
screen shot 2017-06-12 at 16 26 56

@stephenc
Copy link
Member Author

New UI for Branch Source showing the Bitbucket specific traits

screen shot 2017-06-12 at 16 38 50

@stephenc
Copy link
Member Author

New UI for Navigator showing a legacy job upgraded:

screen shot 2017-06-12 at 16 42 21

@stephenc
Copy link
Member Author

@rsandell I think I have addressed everything

Copy link
Member

@rsandell rsandell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🐝

</f:advanced>
<j:jelly xmlns:j="jelly:core" xmlns:f="/lib/form" xmlns:c="/lib/credentials" xmlns:scm="/jenkins/scm/api/form">
<j:choose>
<j:when test="${descriptor.serverUrlSelectable}">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something seem wrong here.
We don't get the the drop down and/or unable to provide the Bitbicket Server url.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forget that...
Found the config within the global configuration.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However.
the help tooltip

The list of servers is configured in the Manage Jenkins » Configure Jenkins › Bitbucket Endpoints screen. The list of servers can include both Bitbucket Cloud as well as Bitbucket Server instances.

Should be attach to the parent UI object.
Since the help is «invisibleEntry» on installation, it doesn't provide much help.

@nfalco79
Copy link
Member

I'm trying this PR because I need it like the water for the elephants.

I would just notify a change in behaviour or maybe a wrong help.
In the past the filter branch (now called "Filter by name with wildcards") matches the git name of the branch and based on that cute off the respective branches and PR folders.
For example:

  • filter: master feature/*
  • accept both feature/123 and PR-34 folder (that comes from feature/123)
  • reject PR-45 because it comes from demo branch (it does not matches filter)

Now the filter was applied on the folder name instead branch
For example:

  • filter: master feature/*
  • accept feature/123 folder
  • reject PR-34 that comes from feature/123

Actually I found a workaround to get it work

  • filter: master feature/* PR-*
  • accept feature/123 folder
  • accept PR-34 that comes from feature/123 (becuase matches PR-*)
  • accept PR-45 that comes from demo branch (originally rejected)

If this new behaviour is expected than fix the help of Filter by name that actually says:

Space-separated list of branch name patterns to consider. You may use * as a wildcard; for example: master release*

into

Space-separated list of patterns to consider. You may use * as a wildcard; for example: master release* PR-*

Copy link
Member

@rsandell rsandell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🐝

@nfalco79
Copy link
Member

nfalco79 commented Jun 30, 2017

I'm using BB Cloud.

I want notify that with latest 3.4.0-alpha-4 the hook management is broken.
Our configuration is enable webhook in BB Cloud settings repo by repo because devOps team has not admin grants on repositories.
With previous (released) version each commit triggers a new build (branch event), now no more build are triggered. I have to setup the job to schedule index every 15 minutes to trigger builds (branch indexing).

* @return the URL of the endpoint.
*/
@NonNull
public abstract String getServerUrl();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this unique across all bitbucket server endpoints?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes dedup on save

* @return the name to use for the end-point
*/
@CheckForNull
public abstract String getDisplayName();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why optional? Might be better to keep it as required, otherwise UI rendering of it could look awkward with blank names appearing in drop down. Same goes for duplicates.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because we display ${displayName} (${serverUrl}) if provided or ${serverUrl} if not and the server URL is unique

Copy link
Contributor

@vivek vivek Jul 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, even in this case, if the intent is to display the name and url, why not have user enter them, it helps him identify these servers later on.

@i386 In BB mock-ups for blueocean, endpoint names appear in drop down box. I am enforcing name requirement via blueocean API and uniqueness (just like GitHub Enterprise), but there is mismatch with the ones created using classic UI. your thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vivek is there a mismatch between how Bitbucket and Github handle endpoint names via classic too?

Why are names not unique? Seems an odd decision

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stephenc if the endpoint name is mandatory for Github can it also be mandatory for Bitbucket? Consistency in these areas makes a huge difference for us in Blue Ocean. Ping @vivek for details.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also URLs can be crazy long. Makes it difficult to disambiguate them in a combo box.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a breaking change, because we can return for you the computed name if the name is not present or blank.

GitHub and BitBucket URLs are not going to be crazy long, because those services demand a root URL so it is basically just the hostname.

Users are going to want to see the URL that the display name corresponds to anyway...

Which GitHub is https://github3.example.com? is that Production or QA?

So we need to add the URL to the display name to help the user

Which GitHub is https://github3.example.com? is that Production (https://github3.example.com) or QA (https://github2.example.com)

This is because the user is used to the GIT URL.

They will know the host name

Copy link
Member

@michaelneale michaelneale Jul 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🐛 talk to some users - ask what their corporate URLs are like. LONG is very very common, and it doesn't have to be that long to make it useless in a drop down in any case. A unique name seems reasonable (in the classic UI it could compute one or make it the URL if they really don't want to type one in - if it is unique right?). If not long, then they are horrible and non memorable.

The users will not know the hostnames off by heart in most of the occasions (ie literally more than half - sure lots will know it).

As an example, I asked a friend from a "Big Company" (everyone has heard it, and uses it often) to rattle one off he used today: http://sj1010212072143.corp.[REDACTED]/ was his first one. That is surprisingly short but ugh...

Some treat them as a hash of something (I have seen stranger things...)

And making things consistent by breaking GHE behaviour is not the way to make things consistent of course (consistency isn't worth that price)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which is why the name is "${displayName == null ? serverUrl : displayName + ' ('+serverUrl+')'}"

If we don't display the server url then we end up with people putting the server url in the display name, or worse putting the wrong server url in the display name.

If we provide the display name then we need to dedup on both otherwise the display name is meaningless or requires the server url anyway.

For the user to be able to trust the server url part of the display name, it has to be appended programmatically not relying on the admin.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok in that case - I think the displayName is pointless. just use serverUrl which is both definitive and unique. If there is to be a "display Name" as above - it is more like an optional description and the UI can decide what to do with it, not lower level code. So for now - displayName is dead - serverUrl is the go. Having something optional which is sometimes used and sometimes not just muddles things - if serverUrl is enough, lets stick with just it. If people complain about crazy URLs in the future, then we can address it (easier to add, than to undo)

* @return the name to use for the end-point
*/
@CheckForNull
public abstract String getDisplayName();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vivek is there a mismatch between how Bitbucket and Github handle endpoint names via classic too?

Why are names not unique? Seems an odd decision

@vivek
Copy link
Contributor

vivek commented Jul 3, 2017

@i386 Yes in classic, GitHub makes name mandatory where as for bitbucket its optional. Both Github and Bitbucket require api url uniqueness. Neither require name to be unique.

@michaelneale
Copy link
Member

michaelneale commented Jul 3, 2017

-1 due to naming discussion above only. Unfortunately I don't have a day to day use of bitbucket at all (unlike some who own $TEAM shares ;) - so just looking at the code/API.

</properties>
<properties>
<jenkins.version>1.642.3</jenkins.version>
<scm-api.version>2.2.0-alpha-1</scm-api.version>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be 2.2.0-SNAPSHOT to match what is in master?

@stephenc stephenc merged commit 2379c9b into jenkinsci:master Jul 5, 2017
@stephenc stephenc deleted the jenkins-43507 branch July 5, 2017 21:46
@abishek3876 abishek3876 mentioned this pull request Jul 13, 2017
fengxx pushed a commit to fengxx/bitbucket-branch-source-plugin that referenced this pull request Mar 13, 2018
[FIXED JENKINS-39026] Add an abstract base class for simple ViewBranchFilter
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.