-
Notifications
You must be signed in to change notification settings - Fork 355
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
Conversation
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)
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. |
(build failure is just -SNAPSHOT dependency missing... will be fixed after I get the GitHub PR ready, if not before) |
@rsandell I think I have addressed everything |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🐝
…rce-2.2.0-alpha-1
</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}"> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
- Pick up updated git and mercurial dependencies - Pick up structs plugin 1.9 - Ensure consistent behaviour for new code
…rce-2.2.0-alpha-4
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.
Now the filter was applied on the folder name instead branch
Actually I found a workaround to get it work
If this new behaviour is expected than fix the help of Filter by name that actually says:
into
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🐝
I'm using BB Cloud. I want notify that with latest 3.4.0-alpha-4 the hook management is broken. |
* @return the URL of the endpoint. | ||
*/ | ||
@NonNull | ||
public abstract String getServerUrl(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 thatProduction
orQA
?
So we need to add the URL to the display name to help the user
Which GitHub is
https://github3.example.com
? is thatProduction (https://github3.example.com)
orQA (https://github2.example.com)
This is because the user is used to the GIT URL.
They will know the host name
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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
@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. |
-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> |
There was a problem hiding this comment.
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?
[FIXED JENKINS-39026] Add an abstract base class for simple ViewBranchFilter
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