-
Notifications
You must be signed in to change notification settings - Fork 136
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
Calls to Bitbucket sometimes fail with com.atlassian.bitbucket.AuthorisationException error #183
Comments
Do you use external authentication provider like AD or Crowd? |
No |
I think in any case you should refer bitbucket logs to see which account had denied access, the exception comes from bitbucket |
I get such errors when Bitbucket cannot connect to our Crowd server, which cannot connect to AD (that`s the lack of AD). It rarely happens but it`s nagging us because the opened PR freezes in |
@scaytrase Do you think we could introduce an extra option like |
@darxriggs we can, but I hope such options should come from Jenkins side (in the inversed variant, like If every plugin introduce it's own option for the same mechanics it would be strange and inconsistent. I really see no reason in failing entire build in case of failed notification, as soon it's only notification but it's only my opinion. How do other notification plugin resolve this issue? At least we can adopt the same approach, I think |
I had a look at some other plugins a while back regarding such error handling. There is no common approach visible. |
Plugin version - 1.11.6
Time to time notifications are failing with the next error, so Bitbucket doesn't receive such notifications:
Failed to notify Stash for commit 509950484482c15754de1cdb5aa5537d8bf318a2 ({"errors":[{"context":null,"message":"You are not permitted to access this resource","exceptionName":"com.atlassian.bitbucket.AuthorisationException"}]})
E.g. the next case is possible:
the issue is reproduced in a Jenkins job build, then other builds of the same job successfully send notifications without any configuration/credential changes, then the issue is reproduced again in subsequent builds, ...
The text was updated successfully, but these errors were encountered: