-
Bug
-
Resolution: Fixed
-
Minor
-
Jenkins:
Core: 2.89
Plugins: latest on experimental update center, including Blue Ocean 1.3.2
bitbucket-branch-source 2.2.7
Client:
Fedora Workstation 26
Chrome 62.0.3202.89
SCM:
Bitbucket Server 5.2.3
-
-
Pipeline - December
Summary:
After successfully connecting to a repo on a Bitbucket server which has code, but does not have a Jenkinsfile in it, attempting to create one fails in Blue Ocean. The only error message shown is the word "Found" in red text. This is caused by setting up the Bitbucket server with an HTTP URL, rather than an HTTPS URL. Changing from HTTP to HTTPS resolves the issue.
Routing:
It's unclear to me at the moment if this is an issue in bitbucket-branch-source, in BO itself, in the editor, or somewhere else.
Steps to recreate:
1. Make a local clone of the simple-maven-project-with-tests repo found here.
2. On your Bitbucket server, create a repository, which you'll use as a remote for this repo you just cloned:
3. Using Blue Ocean, connect to this Bitbucket server by providing your credentials. Shown below, I've gotten as far as having found the repo, but have not yet selected it:
4. Click "Create Pipeline." You'll be told there are no Jenkinsfiles, which is expected.
5. Click the second "Create Pipeline" button which was just generated, and you'll be taken to the editor:
6. Leave Agent set to any (the default), and click the 
button to create a stage. Add a Shell Script step, and enter mvn -X clean package as the step:
7. Click Save, enter a commit message, and leave the default setting of Commit to master. Click Save and Run, and notice the Error at the top of this same dialog:
8. This can also be recreated by using a different branch name than master.
Why this is a problem:
- I've been given no direction as far as what has gone wrong.
- There's nothing at all in the Jenkins log
Later this evening, I'll capture a HAR file while retracing my steps.
- mentioned in
-
Page Failed to load
[JENKINS-47984] Adding Bitbucket server with http instead of https URL breaks Creation flow
Just happened to be tailing my Jenkins log, and spotted this:
Nov 14, 2017 1:20:38 AM jenkins.branch.MultiBranchProject$BranchIndexing run
INFO: simple-maven-project-with-tests #20171114.012038 branch indexing action completed: SUCCESS in 0.31 sec
Nov 14, 2017 1:20:43 AM io.jenkins.blueocean.autofavorite.FavoritingScmListener onCheckout
INFO: Automatically favorited simple-maven-project-with-tests/not-using-editor for kshultz
Nov 14, 2017 1:20:53 AM org.jenkinsci.plugins.workflow.job.WorkflowRun finish
INFO: simple-maven-project-with-tests/not-using-editor #1 completed: SUCCESS
Nov 14, 2017 1:22:01 AM org.apache.http.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {}->http://bitbucket.beescloud.com:80: Broken pipe
Nov 14, 2017 1:22:01 AM org.apache.http.impl.execchain.RetryExec execute
INFO: Retrying request to {}->http://bitbucket.beescloud.com:80
kshultz and this is specific to 2.2.7 or 2.2.6? ie not before
https://github.com/jenkinsci/blueocean-plugin/pull/1492 has test that can help cover this too BTW.
Hey vivek any ideas if this is a regression in BBBS or blue ocean?
michaelneale, I just recreated this with BBBS 2.2.5. So, not specific to >= 2.2.6.
vivek, I've been using the internal BB server. You're welcome to use the same repo, it's under the november project. There's only one repo, feel free to create branches and do whatever you'd like.
I think I have found root cause.
When I add my bitbucket server with an https URL, the issue goes away. But when I enter it with an http address, the issue appears. This is a pretty easy mistake to make, so I think it should still be fixed. Particularly considering that the guidance Bitbucket itself provides, uses http URLs. I'm talking about this guidance when creating a brand new repo:
Severity and subject line changed to reflect these findings.
kshultz If I understand it, BB server is running behind HTTPS and the bug is where we try to create pipeline using the repo with 'http' scheme instead of 'https'? Can you also attach HAR file?
kshultz Does all work with locally running BB server? locally it always runs via http.
vivek, that's correct. I added the server using an http URL, probably just out of habit or even a typo. It wasn't intentional. This succeeded. It wasn't until I tried to use the editor to commit a change to the Jenkinsfile that I ran into trouble.
I had to reboot back into Windows to help with a Webinar this morning. Let me jump back to Linux and I should be able to try the local Bitbucket server. You mean via the Atlassian SDK, right?
> Vivek Pandey, that's correct. I added the server using an http URL, probably just out of habit or even a typo. It wasn't intentional. This succeeded. It wasn't until I tried to use the editor to commit a change to the Jenkinsfile that I ran into trouble.
thanks.
> I had to reboot back into Windows to help with a Webinar this morning. Let me jump back to Linux and I should be able to try the local Bitbucket server. You mean via the Atlassian SDK, right?
Yes.
.HAR now attached. It tracks the process from first connecting to the server with an http URL, to the eventually-failing attempt to save changes to the Pipeline via the editor. Before taking the recording, I deleted my existing Bitbucket Server connections in /manage, and also deleted the preexisting job.
Hopefully that helps. Let me know if it doesn't and I'm happy to retake it.
kshultz Ah, problem found. Issue is really that bitbucket server is setup with https and it wants us to use https one. When you give http://bitbucket.beescloud.com as bb server endpoint url we check if its valid url and save this URL. Later on when pipeline editor tries to save Jenkinsfile, bb server api returns 302 that it fails to handle.
I think the fix is simply to handle 302. Please note this has nothing to do with bitbucket-branch-source latest version. This bug exists in all versions of blueocean. Its minor in nature as workaround is or perhaps right way is for users to setup bb server using https url.
To understand whats going on see the following call below sends 302 with location header pointing to correct https based url.
$ curl -v -H 'accept: application/json' "http:///bitbucket.beescloud.com/" * Unwillingly accepted illegal URL using 3 slashes! * Trying 52.22.14.249... * TCP_NODELAY set * Connected to bitbucket.beescloud.com (52.22.14.249) port 80 (#0) > GET / HTTP/1.1 > Host: bitbucket.beescloud.com > User-Agent: curl/7.54.0 > accept: application/json > < HTTP/1.1 302 Found < Cache-Control: no-cache < Content-length: 0 < Location: https://bitbucket.beescloud.com/ < Connection: close < * Closing connection 0
The entire flow works fine when connecting to a local Bitbucket instance running from the Atlassian SDK. I connected using an http URL as requested, and created this with the editor:
Granted, this isn't the same Jenkins instance as I was originally using. But the plugin levels should be the same, since they're all coming from the experimental UC. BBBS is 2.2.7 on both.
Heh, great minds. I confirmed in my comment this morning that this has nothing to do with 2.2.7. I recreated it with 2.2.5. Didn't bother to go back any farther than that.
Handling the 302 sounds like a fine way to go about it. Entering http instead of https is a mistake which is pretty easy to make. Some sort of guidance for users who do this would be a nice usability enhancement.
actually for 302 and APIs, I don't think they should be automatically followed/handled. telling the user to use the correct URL is the way. Generally with APIs it is a no no to automatically follow redirect requests less the credentials get sent to the wrong place (that is my understanding at least, as to why most libraries won't do it for you).
michaelneale I am not sure about that. Generally such policies are applied at API endpoint not client. For example GitHub API suggests clients to handle 302 by retrying with the url in Location header. https://developer.github.com/v3/#http-redirects. Basically if API endpoint is telling client to follow at a different url client should do it. Same goes for AWS S3, http://docs.aws.amazon.com/AmazonS3/latest/dev/Redirects.html.
vivek ok in that case I revoke my statement, yes should be honoured. The fact that github say this implies they would likely change their mind and move apis around, so should follow it (I guess Bitbucket would have same policy). Good digging
michaelnealekshultz bitbucket API docs do not talk about handling of 302. So I talked to Bitbucket guys about it. They suggested disabling auto-redirect. I think its best we report error and tell users that bitbucket is suggesting a different URL to be used and users should use that instead.
Reduced scope to Minor as using incorrect URL (http instead of https if bb server is running behind https) is expected to fail during creation flow. The fix is going to be fail early/fast instead of at the very end when Jenkinsfile is saved.
Update:
It's actually nothing to do with creation of a Jenkinsfile in an existing repo which doesn't have one. I've tried some other things, and can't modify existing Jenkinsfiles, either.
1. Using the same local repo, I checked out a new branch, created a Jenkinsfile in it, and pushed to the remote:
✔ ~/Documents/CloudBees/Work/BlueOcean1.4/bitbucket-branch-source-repos/simple-maven-project-with-tests [master|…16] 19:42 $ git checkout -b "not-using-editor" Switched to a new branch 'not-using-editor' ✔ ~/Documents/CloudBees/Work/BlueOcean1.4/bitbucket-branch-source-repos/simple-maven-project-with-tests [not-using-editor L|…16] 19:42 $ vi Jenkinsfile ✔ ~/Documents/CloudBees/Work/BlueOcean1.4/bitbucket-branch-source-repos/simple-maven-project-with-tests [not-using-editor L|●1…1] 19:44 $ git status On branch not-using-editor Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: Jenkinsfile Untracked files: (use "git add <file>..." to include in what will be committed) .gitignore ✔ ~/Documents/CloudBees/Work/BlueOcean1.4/bitbucket-branch-source-repos/simple-maven-project-with-tests [not-using-editor L|●1…1] 19:44 $ git add .gitignore ✘-1 ~/Documents/CloudBees/Work/BlueOcean1.4/bitbucket-branch-source-repos/simple-maven-project-with-tests [not-using-editor L|●2] 19:45 $ git commit -m "Editor not being used for this. See if I can build in BO after the Jenkinsfile is up. If I can, we have an issue." [not-using-editor 715d51c] Editor not being used for this. See if I can build in BO after the Jenkinsfile is up. If I can, we have an issue. 2 files changed, 37 insertions(+) create mode 100644 .gitignore create mode 100644 Jenkinsfile ✔ ~/Documents/CloudBees/Work/BlueOcean1.4/bitbucket-branch-source-repos/simple-maven-project-with-tests [not-using-editor L|✔] 19:45 $ git push fatal: The current branch not-using-editor has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin not-using-editor ✘-128 ~/Documents/CloudBees/Work/BlueOcean1.4/bitbucket-branch-source-repos/simple-maven-project-with-tests [not-using-editor L|✔] 19:45 $ git push --set-upstream origin not-using-editor warning: redirecting to https://bitbucket.beescloud.com/scm/nov/simple-maven-project-with-tests.git/ Counting objects: 4, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (4/4), 775 bytes | 775.00 KiB/s, done. Total 4 (delta 0), reused 0 (delta 0) remote: remote: Create pull request for not-using-editor: remote: http://bitbucket.beescloud.com/projects/NOV/repos/simple-maven-project-with-tests/compare/commits?sourceBranch=refs/heads/not-using-editor remote: To http://bitbucket.beescloud.com/scm/nov/simple-maven-project-with-tests.git * [new branch] not-using-editor -> not-using-editor Branch not-using-editor set up to track remote branch not-using-editor from origin. ✔ ~/Documents/CloudBees/Work/BlueOcean1.4/bitbucket-branch-source-repos/simple-maven-project-with-tests [not-using-editor|✔]2. Verify that the Jenkinsfile made it over to the new branch:
3. I deleted the repo, and rediscovered it using Blue Ocean. The original branch not-using-editor built successfully.
4. I then edited the Pipeline using the editor, and attempted to save my changes to a new branch:
5. Same result when attempting to save to the new branch: