search

jenkinsci / bitbucket-branch-source-plugin

Bitbucket Branch Source Plugin
https://plugins.jenkins.io/cloudbees-bitbucket-branch-source
MIT License
217 stars 352 forks source link

Pull-Requests no longer working on BitBucket Server 7.0 #287

Closed viceice closed 4 years ago

viceice commented 4 years ago

Your checklist for this issue

Description

This plugin is no longer able to fetch and build pull-requests. Looks like thay changed the api without writing a note.

06:01:26  Started by user XXX YYY
06:01:26  Running as XXX YYY
06:01:34  ERROR: Could not do lightweight checkout, falling back to heavyweight
06:01:34  java.io.FileNotFoundException: URL: /rest/api/1.0/projects/proj/repos/repo/browse/Jenkinsfile?at=pull-requests%2F580%2Fmerge&start=0&limit=500
06:01:34    at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getRequest(BitbucketServerAPIClient.java:831)
06:01:34    at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getFileContent(BitbucketServerAPIClient.java:1123)
06:01:34    at com.cloudbees.jenkins.plugins.bitbucket.filesystem.BitbucketSCMFile.content(BitbucketSCMFile.java:98)
06:01:34    at jenkins.scm.api.SCMFile.contentAsString(SCMFile.java:335)
06:01:34    at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:107)
06:01:34    at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:299)
06:01:34    at hudson.model.ResourceController.execute(ResourceController.java:97)
06:01:34    at hudson.model.Executor.run(Executor.java:427)
06:01:34  Checking out git https://xxx.yyyy.de/scm/proj/repo.git https://xxx.yyyy.de/scm/proj/repo.git into /var/jenkins_home/workspace/proj_repo_PR-580@script to read Jenkinsfile
06:01:34  using credential a63b7cb8-6690-4c0b-81b8-93969a0fabac
06:01:35  using credential a63b7cb8-6690-4c0b-81b8-93969a0fabac
06:01:35   > git rev-parse --is-inside-work-tree # timeout=10
06:01:35  Fetching changes from 2 remote Git repositories
06:01:35   > git config remote.origin.url https://xxx.yyyy.de/scm/proj/repo.git # timeout=10
06:01:35  Cleaning workspace
06:01:35   > git rev-parse --verify HEAD # timeout=10
06:01:35  No valid HEAD. Skipping the resetting
06:01:35   > git clean -ffdx # timeout=10
06:01:35  Pruning obsolete local branches
06:01:35  Fetching upstream changes from https://xxx.yyyy.de/scm/proj/repo.git
06:01:35   > git --version # timeout=10
06:01:35  using GIT_ASKPASS to set credentials 
06:01:35   > git fetch --tags --force --progress --prune -- https://xxx.yyyy.de/scm/proj/repo.git +refs/pull-requests/580/from:refs/remotes/origin/PR-580 # timeout=10
06:01:35  ERROR: Error fetching remote repo 'origin'
06:01:35  hudson.plugins.git.GitException: Failed to fetch from https://xxx.yyyy.de/scm/proj/repo.git
06:01:35    at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:909)
06:01:35    at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131)
06:01:35    at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167)
06:01:35    at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:124)
06:01:35    at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:155)
06:01:35    at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:142)
06:01:35    at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:299)
06:01:35    at hudson.model.ResourceController.execute(ResourceController.java:97)
06:01:35    at hudson.model.Executor.run(Executor.java:427)
06:01:35  Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --force --progress --prune -- https://xxx.yyyy.de/scm/proj/repo.git +refs/pull-requests/580/from:refs/remotes/origin/PR-580" returned status code 128:
06:01:35  stdout: 
06:01:35  stderr: fatal: Couldn't find remote ref refs/pull-requests/580/from
06:01:35  
06:01:35    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2430)
06:01:35    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2044)
06:01:35    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:81)
06:01:35    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:569)
06:01:35    at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:907)
06:01:35    ... 8 more
06:01:35  ERROR: Error fetching remote repo 'origin'
06:01:35  [Bitbucket] Notifying pull request build result
06:01:36  [Bitbucket] Build result notified
06:01:36  ERROR: Maximum checkout retry attempts reached, aborting
06:01:36  Finished: FAILURE

https://community.atlassian.com/t5/Bitbucket-questions/Bitbucket-Server-7-0-PR-fetch-from-not-working/qaq-p/1320053

tomk3003 commented 4 years ago

Thanks, I will do this first thing tomorrow morning and give an update.

tomk3003 commented 4 years ago

Ok, tested the RC release @wololock mentioned. But the behaviour does not change. PRs from forks are not recognized. PRs in the same repo are working without problems. After opening the PR in Bitbucket the PRs from forks are recognized with a rescan.

tomk3003 commented 4 years ago

But now the PR from forks cannot be built at all with the same error I posted in my first post. Even with a completly new PR. I will reinstall the latest RC and check again. I hope I can get the semi working state back.

tomk3003 commented 4 years ago

Ok, back to the latest RC and I can use the PRs again with the manual workaroud. But now the "repo-local" PRs suffer from the same problem and have to be triggered manually. So it seems the last RC did fix part of the problem for the forked PRs but this affected the repo-local PRs as well.

muppet3000 commented 4 years ago

Does the latest release imply that this ticket can now be closed? The linked issue implies there may be something else that is now broken. Can someone comment here on the new status?

jetersen commented 4 years ago

This is still not resolved.

muppet3000 commented 4 years ago

@jetersen Thanks for the update. Do we know if there's an RC build of the latest release e.g. 2.8.1 that has the PR code merged into it? Or should we be taking the previous RC still? Is there a way of tracking which RC builds have which PRs etc. in them?

mattiassluis commented 4 years ago

I think PR https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/294 fixes this at least to a decent level. I think it is almost done but needs some docs, perhaps @jetersen can reply to the last question on the PR. After that it can hopefully be merged and released? 🙏

muppet3000 commented 4 years ago

Awesome. It would be great to have an RC build rebased on top of the latest release so we can confirm they all work together. It will also stop our Jenkins instance from complaining that there are out-of-date plugins :P Happy to test as soon as there's another RC available. Genuinely interested in how/when the RCs are built especially if there's a way of knowing what's in each of them.

mattiassluis commented 4 years ago

The latest RC includes the latest 2.8.0 release (hence the 2.8.1-rc naming). I think it holds that + the changes of a specific pull request (you can identify them on the commit hash in the name and related them to a commit of a specific PR)

muppet3000 commented 4 years ago

Ah yes, that tracks with the previous build mentioned above with the "f242e6" branch. Now it's just a case of getting a build that includes all of your latest changes. I assume it's something that the plugin owner is in control of.

mattiassluis commented 4 years ago

I think that will require an official release or at least for the PRs to be merged. I would also love to see that once the PRs to resolve Bitbucket 7 issues are finished

jetersen commented 4 years ago

I merged master into the PR, so you will have a the latest. Usually Jenkins will do a merge but better safe than sorry :)

muppet3000 commented 4 years ago

@jetersen How does the build end up on the servers here: https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/cloudbees-bitbucket-branch-source/ ?

Is that something you control, or is it the central Jenkins/cloudbees servers that control that?

jetersen commented 4 years ago

@muppet3000 like this: https://github.com/jenkins-infra/pipeline-library/blob/148485040122e8d2f6faec30b54b119740515a57/vars/buildPlugin.groovy#L203-L205 https://github.com/jenkins-infra/pipeline-library/blob/148485040122e8d2f6faec30b54b119740515a57/vars/infra.groovy#L259-L279 https://github.com/jenkinsci/incrementals-tools

muppet3000 commented 4 years ago

@jetersen Thanks for the info.

For anyone else that wants to test, the latest build is here: https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/cloudbees-bitbucket-branch-source/2.8.1-rc646.71e4d09c0b37/

We'll update a couple of our instances and report back if anything is broken (otherwise assume it's fine).

muppet3000 commented 4 years ago

Looks good, we still see the "Lightweight checkout failed" issue, but I assume that's to be expected.

mattiassluis commented 4 years ago

I think Bitbucket made it impossible to do a lightweight checkout for a the merged version of the pull request. That ref that was accessed through the API of Bitbucket no longer exists leaving two options: 1) Heavy weight checkout (doing the merge on Jenkins) 2) Switch to building the PR without the merge (which most of us find undesirable) I don't think this feature will come back anytime soon but maybe a feature can be created to choose where the Jenkinsfile should be pulled from (separately from how the code should be build): 1 - From the target branch 2 - From the PR (without merge with the target branch) 3 - Merged (requires heavyweight checkout on Bitbucket Server 7+)

muppet3000 commented 4 years ago

Cool. I have no problem with a heavyweight build. The thought of not having the code merged in the build seems pointless!

tomk3003 commented 4 years ago

I will be able to test this on sunday.

muppet3000 commented 4 years ago

I spoke too soon. The latest merge or latest changes have reverted back to the previous cloning behaviour. e.g.:

git fetch --no-tags --progress -- https://<BITBUCKET_REPO_URL>.git +refs/pull-requests/78/from:refs/remotes/origin/PR-78 # timeout=10

however, the previous RC of the plugin switched to using the following: git fetch --no-tags --progress -- https://<BITBUCKET_REPO_URL>.git +refs/heads/<PR-SOURCE-BRANCH>:refs/remotes/origin/<PR-SOURCE-BRANCH># timeout=10

Hopefully the above makes sense with all the obfuscation of URLs and repo names

The reason I thought it worked is because for some reason our Bitbucket instance is still creating the old style of ref but on it's own timescale and there's no guarantee that it will exist. As such, when I tested the upgrade on a PR that already existed, it worked first time. Also, in some cases, if Bitbucket creates the ref quickly enough before the Jenkins instance actions the webhook it will also appear to work correctly.

Not sure how this has happened, potentially the merge in from master? Interested to see & test a fix when it's available.

For now, we're reverting back to the previous RC which is working fine.

mattiassluis commented 4 years ago

Did you make sure to check the checkbox 'callChanges' in the configuration? That should ensure the ref exists before cloning?

muppet3000 commented 4 years ago

@mattiassluis No I didn't, I expected the plugin to work how it always has done. I'll test it with your suggestion now. What is the correct behaviour out of the two examples I posted above then? What is the scenario where you wouldn't want to "callChanges"? Surely you always want to ensure that the PR exists before you try to pull it?

mattiassluis commented 4 years ago

I think the scenario where you wouldn't want this is when you are running Bitbucket Server < 7. I just installed the latest RC as well, we still see some strange cases where sometimes it works and other times it doesn't. Maybe the latest RC resolves that. It seems to work fine on new pull requests but when updating pull requests it is not really clear what happens. Of course we rebase a lot which suggests it also needs the fix I made to be included to handle the new incoming event as well.

muppet3000 commented 4 years ago

Ok makes sense. Would be great if the plugin could intelligently decide whether to call it or not i.e. by looking at the REST API of bitbucket and finding out what version it was. There are 2 options now in the configuration of the plugin:

The latter has a helpful message including "(since BitBucket Server v7)", but the first one doesn't say if it's specific to > BB v 7 or not.

I've ticked them both but I'm not sure if that's the correct thing to do. It does appear to have fixed the problem though.

joaoportela commented 4 years ago

We're having the same issue. The PR #294 seems to fix it.

We got the build 2.8.1-rc648.98e3c549af77 from jenkins-ci repo.

We enabled the "Call Changes API" option at https://SERVERADDRESS/configure like you guys said. image

Unfortunately, it still falls back to heavyweight checkout but at least the heavyweight checkout is working. 😄

viceice commented 4 years ago

lightweight checkout is no longer possible with bitbucket server v7 and merge build strategy, because bitbucket no longer computes a merge commit.

joaoportela commented 4 years ago

Just another update from my side.

Looking at the build logs and comparing it with PR #294 changes it didn't seem to be using the "Call changes API" code path.

So I unchecked that option and ran the builds again and it still works... 🤷‍♂️

I guess the issue for me was something else that hasn't made it into stable release yet.

More details if you guys need it:

mattiassluis commented 4 years ago

@joaoportela actually that makes perfect sense if you didn't push any new changes in between. The "Call changes API" only needs to be called once to ensure the refs are created on Bitbucket. This is also what happens if you view the diff in the Bitbucket UI. Once the refs are created the plugin can do its thing (with the heavyweight checkout). What the "Call changes API" does is ensure that Bitbucket for sure created the refs (because with Bitbucket 7 they are only created on demand).

mattiassluis commented 4 years ago

With regards to my earlier comment: https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/287#issuecomment-625283903 This seems to be some mistake with the webhooks on our end. The latest releases have worked good for us (but since we need to roll this out to many Jenkins servers we are hoping on an official release soon)

tomk3003 commented 4 years ago

I just tested with 2.8.1-rc648.98e3c549af77 with "Call Changes api" activated and "Can Call Merge" deactivated against Bitbucket Server 7.1.2 and can confirm that PRs from within a repo as well as PRs from forks are triggered successfully.. The only thing that is still missing, is triggering a build when a PR gets pushed into. But I think for that, handling of the new webhook "Source branch updated" (#308) is needed.

JeroennC commented 4 years ago

Another github user @Cyanoth (thanks!) created an alternative solution to this issue, creating a bitbucket plugin that executes the diff call whenever a PR is created / updated: https://github.com/Cyanoth/Bitbucket-EagerPR-Updates

We've just installed this to our bitbucket server, and it works well. I'm not sure if it guarantees the refs/pull-requests/<x>/from ref is updated before the Jenkins job is triggered though.

I also like how this solution works regardless of the CI used. Would be best if this plugin still gets #294 though IMO

spacehorst commented 4 years ago

I confirm tomk3030. 2.8.1-rc648.98e3c549af77 works with Bitbucket Server 7.1.0 setting "Call Changes API" true and "Can Call Merge" false. Even a subsequent push to the source branch triggered a rebuild of the PR.

mike-sol commented 4 years ago

Still seeing this issue on the first build of a multibranch pipeline with 2.8.1-rc648.98e3c549af77 installed. Subsequent, manually triggered builds seem to work.

Running against Bitbucket Server 7.3.0 and happy to try out new builds of the plugin on Jenkins.


ERROR: Could not do lightweight checkout, falling back to heavyweight
java.io.FileNotFoundException: URL: /rest/api/1.0/projects/REPONAME/repos/REPONAME/browse/rpm/pipelines/pull-request/Jenkinsfile?at=pull-requests%2F2636%2Fmerge&start=0&limit=500
    at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getRequest(BitbucketServerAPIClient.java:855)
    at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getFileContent(BitbucketServerAPIClient.java:1150)
    at com.cloudbees.jenkins.plugins.bitbucket.filesystem.BitbucketSCMFile.content(BitbucketSCMFile.java:98)
    at jenkins.scm.api.SCMFile.contentAsString(SCMFile.java:335)
    at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:107)
    at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:309)
    at hudson.model.ResourceController.execute(ResourceController.java:97)
    at hudson.model.Executor.run(Executor.java:428)
Checking out git https://git.REDACTED.local/scm/REPONAME/REPONAME.git https://git.REDACTED.local/scm/REPONAME/REPONAME.git into /var/lib/jenkins/workspace/SSW_REPONAME-pr-build_PR-2636@script to read rpm/pipelines/pull-request/Jenkinsfile
using credential CREDENTIAL-NAME
using credential CREDENTIAL-NAME
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://git.REDACTED.local/scm/REPONAME/REPONAME.git
 > git init /var/lib/jenkins/workspace/SSW_REPONAME-pr-build_PR-2636@script # timeout=10
Fetching upstream changes from https://git.REDACTED.local/scm/REPONAME/REPONAME.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials Read-only personal access token for stash.jenkins BitBucket user
 > git fetch --no-tags --force --progress -- https://git.REDACTED.local/scm/REPONAME/REPONAME.git +refs/pull-requests/2636/from:refs/remotes/origin/PR-2636 # timeout=10
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git fetch --no-tags --force --progress -- https://git.REDACTED.local/scm/REPONAME/REPONAME.git +refs/pull-requests/2636/from:refs/remotes/origin/PR-2636" returned status code 128:
stdout: 
stderr: fatal: couldn't find remote ref refs/pull-requests/2636/from

    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2430)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2044)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:81)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:569)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:798)
    at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1122)
    at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167)
    at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:125)
    at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:155)
    at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:142)
    at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:309)
    at hudson.model.ResourceController.execute(ResourceController.java:97)
    at hudson.model.Executor.run(Executor.java:428)
ERROR: Error cloning remote repo 'origin'
[Bitbucket] Notifying pull request build result
[Bitbucket] Build result notified
ERROR: Maximum checkout retry attempts reached, aborting
Finished: FAILURE
spacehorst commented 4 years ago

The first build for a new PR is also automatically triggered and successfully built on the before mentioned configuration of our systems.

mike-sol commented 4 years ago

@spacehorst You mention "Bitbucket Server 7.1.0 setting "Call Changes API" true and "Can Call Merge" false" - where does one configure those? Were they non-default settings?

muppet3000 commented 4 years ago

There's a discussion on this a few posts up from myself. Those options are in the settings for the plugin in Jenkins i.e. where you configure the address etc. for your Bitbucket server. They're not on by default because the developer doesn't want to assume that everyone is using the latest version of Bitbucket, if you're running an older version those options will cause the plugin to fail. I believe I made the suggestion that the plugin could query the Bitbucket REST API to find out what version of Bitbucket was being used and then apply the correct setting accordingly. I'm not a Java Dev so I don't really know how hard that is to actually implement.

On Fri, 12 Jun 2020, 01:18 Mike Sollanych, notifications@github.com wrote:

@spacehorst https://github.com/spacehorst You mention "Bitbucket Server 7.1.0 setting "Call Changes API" true and "Can Call Merge" false" - where does one configure those? Were they non-default settings?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/287#issuecomment-642993103, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQ62ZAWUQHFXV2JFL5S55TRWFX3VANCNFSM4LEBNNJQ .

mike-sol commented 4 years ago

Thanks @muppet3000, I have enabled that option and will report back when my devs have tested things out.

mike-sol commented 4 years ago

Looks like we're good over here. Here's the top of the build output from a now-working PR.

It would be nice if it didn't throw the exception, and instead have some way to detect this case and not litter build output with unnecessary errors.


ERROR: Could not do lightweight checkout, falling back to heavyweight
java.io.FileNotFoundException: URL: /rest/api/1.0/projects/REPO/repos/REPO/browse/rpm/pipelines/pull-request/Jenkinsfile?at=pull-requests%2F2647%2Fmerge&start=0&limit=500
    at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getRequest(BitbucketServerAPIClient.java:855)
    at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getFileContent(BitbucketServerAPIClient.java:1150)
    at com.cloudbees.jenkins.plugins.bitbucket.filesystem.BitbucketSCMFile.content(BitbucketSCMFile.java:98)
    at jenkins.scm.api.SCMFile.contentAsString(SCMFile.java:335)
    at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:107)
    at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:309)
    at hudson.model.ResourceController.execute(ResourceController.java:97)
    at hudson.model.Executor.run(Executor.java:428)
Checking out git https://git.COMPANY.local/scm/REPO/REPO.git https://git.COMPANY.local/scm/REPO/REPO.git into /var/lib/jenkins/workspace/SSW_REPO-pr-build_PR-2647@script to read rpm/pipelines/pull-request/Jenkinsfile
using credential CRED
using credential CRED
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://git.COMPANY.local/scm/REPO/REPO.git
 > git init /var/lib/jenkins/workspace/SSW_REPO-pr-build_PR-2647@script # timeout=10
Fetching upstream changes from https://git.COMPANY.local/scm/REPO/REPO.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials Read-only personal access token for stash.jenkins BitBucket user
 > git fetch --no-tags --force --progress -- https://git.COMPANY.local/scm/REPO/REPO.git +refs/pull-requests/2647/from:refs/remotes/origin/PR-2647 # timeout=10
 > git config remote.origin.url https://git.COMPANY.local/scm/REPO/REPO.git # timeout=10
 > git config --add remote.origin.fetch +refs/pull-requests/2647/from:refs/remotes/origin/PR-2647 # timeout=10
 > git config remote.origin.url https://git.COMPANY.local/scm/REPO/REPO.git # timeout=10
Fetching without tags
Fetching upstream changes from https://git.COMPANY.local/scm/REPO/REPO.git
using GIT_ASKPASS to set credentials Read-only personal access token for stash.jenkins BitBucket user
 > git fetch --no-tags --force --progress -- https://git.COMPANY.local/scm/REPO/REPO.git +refs/pull-requests/2647/from:refs/remotes/origin/PR-2647 # timeout=10
 > git config remote.upstream.url https://git.COMPANY.local/scm/REPO/REPO.git # timeout=10
Fetching without tags
Fetching upstream changes from https://git.COMPANY.local/scm/REPO/REPO.git
using GIT_ASKPASS to set credentials Read-only personal access token for stash.jenkins BitBucket user
 > git fetch --no-tags --force --progress -- https://git.COMPANY.local/scm/REPO/REPO.git +refs/heads/master:refs/remotes/upstream/master # timeout=10
Merging remotes/upstream/master commit 96ca0c51ba0d19112daf521fa3e97c2603f7345e into PR head commit fc69bfd35092dd27d31e7c1d1e7774296038c625
 > git config core.sparsecheckout # timeout=10
 > git checkout -f fc69bfd35092dd27d31e7c1d1e7774296038c625 # timeout=10
 > git remote # timeout=10
 > git config --get remote.origin.url # timeout=10
using GIT_ASKPASS to set credentials Read-only personal access token for stash.jenkins BitBucket user
 > git merge 96ca0c51ba0d19112daf521fa3e97c2603f7345e # timeout=10
 > git rev-parse HEAD^{commit} # timeout=10
Merge succeeded, producing fc69bfd35092dd27d31e7c1d1e7774296038c625
Checking out Revision fc69bfd35092dd27d31e7c1d1e7774296038c625 (PR-2647)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f fc69bfd35092dd27d31e7c1d1e7774296038c625 # timeout=10
Commit message: "Revert "Reverting changes to demo.py""
First time build. Skipping changelog.
[Bitbucket] Notifying pull request build result
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline (show)
[Bitbucket] Notifying pull request build result
[Bitbucket] Build result notified
Finished: SUCCESS
jglick commented 4 years ago

It would be nice if it didn't throw the exception, and instead have some way to detect this case and not litter build output with unnecessary errors.

That would have to be in https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/a18e9d41dca08652d2bb2ce71fbf113e9ae5fb5a/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/filesystem/BitbucketSCMFileSystem.java#L100

Be sure to test not just an empty Jenkinsfile but one including

node {
  checkout scm
}
muppet3000 commented 4 years ago

I've just had a new issue brought to my attention on this and I don't know if it's as a result of the changes to the plugin or something else. Would be grateful if others could confirm. We have our Jenkins configured in "Exclude branches that are also filed as PRs", however, quite often someone will make some changes to a feature and push them, then immediately create a PR. This results in a running "feature" branch job, and then another running "PR" job following shortly behind. In bitbucket however, this shows as just a single running job - whatever one was triggered last (in this case the PR), but I'm 100% certain that it used to show as 2 jobs - one for the feature branch and another for the PR branch.

What happens is that the feature job finishes whilst the PR is still running and then updates the job status on the Bitbucket PR/commit to show that the feature branch has passed. This allows a PR to then be merged whilst a job (the PR job) is still running, breaking the whole point of having a PR build (All of our pipelines are configured to do more extensive tests when it's a PR, therefore if a feature branch sneaks in and sets the status to green while there are tests that still haven't been run code can get merged in with failures in it - without anyone realising). When the PR then finishes (slightly later) it then updates the job again with the status of it's build (to the one we actually care about).

Has anyone else seen this behaviour? I'll do more investigation tomorrow to determine whether or not this is related to this plugin, or another plugin. I'll attempt to roll back the plugin we have installed on one of our instances to a "pre dev" build of this one and see if the behaviour persists or goes away, if it goes away then the issue is in this "fix".

Can anyone else out there confirm whether they're seeing the same issue with this dev build of the plugin? We've just upgraded all of our Jenkins instances to the latest LTS and latest plugins, so there have been lots of changes that I need to rule out.

viceice commented 4 years ago

@muppet3000 I've seen this too, this has nothing todo with this issue. So please file a new issue for that

muppet3000 commented 4 years ago

I understand that the symptoms are nothing to do with this issue. My question is more whether or not someone has seen this issue when NOT using this dev build of the plugin. In other words, have the changes implemented to fix this issue accidentally caused a different issue?

On Mon, 29 Jun 2020, 17:25 Michael Kriese, notifications@github.com wrote:

@muppet3000 https://github.com/muppet3000 I've seen this too, this has nothing todo with this issue. So please file a new issue for that

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/287#issuecomment-651225851, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQ62ZE56ED62KD7ZWYT3QLRZC553ANCNFSM4LEBNNJQ .

viceice commented 4 years ago

@muppet3000 sorry, I've seen it before I switch to the dev build. I have some jobs which requires 15 and more minutes to succeed, so if I push a branch and open a PR shortly after it, I can see your behavior on all releases since ~1 year

muppet3000 commented 4 years ago

That's so weird, I'm certain that it used to post multiple build statuses to Bitbucket one for each branch type in Jenkins. I'll put some effort into debugging/analysing it properly tomorrow and log a new issue for people to add their comments to.

On Mon, 29 Jun 2020, 19:43 Michael Kriese, notifications@github.com wrote:

@muppet3000 https://github.com/muppet3000 sorry, I've seen it before I switch to the dev build. I have some jobs which requires 15 and more minutes to succeed, so if I push a branch and open a PR shortly after it, I can see your behavior on all releases since ~1 year

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/287#issuecomment-651293218, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQ62ZDQKHUXRIP6OOTUR5DRZDOEXANCNFSM4LEBNNJQ .

muppet3000 commented 4 years ago

@viceice I've just created this new issue to address the separate problem we discussed yesterday: https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/324 Would appreciate your +1/backing/comments on it to help bump it up the priority.

mlasevich commented 4 years ago

Just run into an issue with falling back to heavyweight checkout. When faced with a repo that has LSF enabled, it tries to do LFS, which is not available on master. My two questions are - have the issue of falling back to heavyweight been resolved here and if not, is there a way to disable LFS during heavyweight checkout for purposes of this plugin while still having it enabled for actual checkout on the remote nodes?

jetersen commented 4 years ago

regarding LFS checkout, I toyed with the idea of either an extension plugin or a contribution to the git plugin to add a scm filter for ignoring LFS checkout on master. Never got anywhere but should be simple to write a filter.

The issue of heavy checkout has not been resolved.

One simple solution is to add this environment variable on Jenkins master: GIT_LFS_SKIP_SMUDGE=1 Or run this command to ignore LFS checkout: git config --global filter.lfs.smudge "git-lfs smudge --skip"

jetersen commented 4 years ago

Added workarounds for LFS checkout on master in the above message so to write plugin might seem overkill.

mlasevich commented 4 years ago

Thanks. For now I removed the LFS from my job config and added it manually in checkout step in Jenkinsfile(hurray for global libs) - but it would be much cleaner using the env variable being that master does not even have LFS installed, so it will not work in any case.