Bitbucket Server: Builds Stay In Progress Forever / Are Created without .tekton dir

[tricktron]

Hi there,

We have the following strange behaviour:

Actual Behaviour

1. Add the PaC user as admin to the bitbucket project.
2. Create the pac webhook with push, modified, opened, source branch updated, comment added events.
3. A user with inherited group admin access opens a pull request:

Observe that the pull request opened event triggers a zombie build which stays in progress forever and does not redirect to the Openshift console if you click on it:

Expected Behaviour

There are actually two expected behaviours:

• If there is no pipelinerun / no .tekton directory then no pipeline should be triggered instead of the zombie build.
• If there is a pipelinerun then it should correctly be triggered and by clicking on the link we should be redirected to the Openshift console.

Workaround / Possible Permission Issue

Currently, the user who opened the pull request has admin access to the Bitbucket repository through the inherited project's group access. If we instead add the user manually as admin to the project's user access then everything works. However, that means we need to add every committer manually to every project as admin which is annoying.

Do you know why each user must be project admin in bitbucket for this to work?

General / Possible Related Tickets

We are using Bitbucket Server v7.21.16 and pac 0.33.x.

#1696
#1726

[chmouel]

cc @zakisk

[zakisk]

So here are two issues:

1. The running status you're seeing, it should have been pending status saying "Pending approval, waiting for an /ok-to-test" but due to wrong conclusion here it is shown as "Running". @tricktron if someone with direct project admin access does a /ok-to-test command then I believe it will disappear and rather a "FAILED" build status will created saying there is no matching PipelineRun. (will fix the running status issue)

2. why inherited project admin are not allowed to run PaC CI? and that's why the pending build status is there (which is running at the moment) and this is something we need to investigate.

[zakisk]

the user who opened the pull request has admin access to the Bitbucket repository through the inherited project's group access.

@tricktron did you mean the group has admin access on project and the user is added on that group, right?

[tricktron]

@zakisk Thank you for your answer.

So here are two issues:

1. The running status you're seeing, it should have been pending status saying "Pending approval, waiting for an /ok-to-test" but due to wrong conclusion here it is shown as "Running". @tricktron if someone with direct project admin access does a /ok-to-test command then I believe it will disappear and rather a "FAILED" build status will created saying there is no matching PipelineRun. (will fix the running status issue)

Ok, now I get it. However, if there is no matching pipelinerun, e.g. no .tekton dir at all then no pipeline should be triggered at all right, or does it trigger a pipeline with the failed status because it has not found a matching pipelinerun?

the user who opened the pull request has admin access to the Bitbucket repository through the inherited project's group access.

@tricktron did you mean the group has admin access on project and the user is added on that group, right?

Yes, if the user is in the devteam group which is admin then he is not allowed to run the pipeline and we again get a forever in progress running zombie build.

However, if you manually add the user as admin under user access (e.g. serviceAccount) then it works. So do we need to add a check for group access here:

pipelines-as-code/pkg/provider/bitbucketserver/acl.go

Line 116 in e0d0ad7

func (v *Provider) checkMemberShip(ctx context.Context, event *info.Event) (bool, error) {

or what is the problem?

[zakisk]

Ok, now I get it. However, if there is no matching pipelinerun, e.g. no .tekton dir at all then no pipeline should be triggered at all right, or does it trigger a pipeline with the failed status because it has not found a matching pipelinerun?

@tricktron this check is not for PipelineRun but to indicate that the user is not allowed to run CI and waiting for admin to approve by /ok-to-test comment.

[tricktron]

@zakisk Ah we are still on pac 0.33.x. So maybe this is fixed with 3dab183?

[zakisk]

@zakisk Ah we are still on pac 0.33.x. So maybe this is fixed with 3dab183?

No! it was just rest library change not a fix.

[zakisk]

there was an issue in the rest library for commit status I made a PR to it will fix the wrong status issue after my PR is merged.
jenkins-x/go-scm#499

[zakisk]

the user who opened the pull request has admin access to the Bitbucket repository through the inherited project's group access.

@tricktron how does the user (in group) is creating pull request? via fork or direct branch on the upstream repo?

[zakisk]

and also how did that user create token? project level or repository or else?

[tricktron]

the user who opened the pull request has admin access to the Bitbucket repository through the inherited project's group access.

@tricktron how does the user (in group) is creating pull request? via fork or direct branch on the upstream repo?

Direct branch on the upstream repo.

and also how did that user create token? project level or repository or else?

As you can see in the screenshot above, we use the service account user as a technical user which has a project admin token to manage pac. The user who then opens the pull request is just a project group admin member.

@zakisk Does this answer your questions?

[zakisk]

As you can see in the screenshot above, we use the service account user as a technical user which has a project admin token to manage pac. The user who then opens the pull request is just a project group admin member.

@zakisk Does this answer your questions?

Yes I think, you're using "technical user" credentials as PaC admin and the author of the pull request is member of the group (which has admin right on repo) but as the author of the pull request directly creating branch in the repository he/she might have created a token to push to the repository so my second question is about that how did that user create token? project level or repository level or else?