You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[JENKINS-74983] Add support for authenticated Webhooks registered in Bitbucket
Verify in the webhooks processor when the signature is present is matches the configured
Add configuration in the global settings to setup HMAC credentials. The secret is not customisable by single project for the following reasons:
* events should contains a duplicate of the payload to be verified only in BitbucketSCMSource.retrieve method.
* that means spend a lot of resources just to ignore the payload. Multiple fake requests, would overload Jenkins that have to process events to lookup the right project.
* could not response to Bitbucket that the payload is invalid because events are managed async.
* each event could serve multiple projects that potentially could be configured with a different secret.
.. A Bitbucket Data Center Project ID: all repositories in the project are imported as Multibranch projects. *Note that the project ID needs to be used instead of the project name*.
77
77
.. A regular username: all repositories which the username is owner of are imported.
78
78
+
79
-
image::images/screenshot-8.png[scaledwidth=90%]
79
+
image::images/screenshot-8.png
80
80
81
81
. Save the configuration. The initial indexing process starts. Once it finishes, a Multibranch
82
82
project is created for each repository.
83
83
+
84
-
image::images/screenshot-9.png[scaledwidth=90%]
84
+
image::images/screenshot-9.png
85
85
86
86
[id=bitbucket-avatar]
87
87
== Avatar
88
88
89
89
This plugin have customized icon designed for the "Organization Folder" image:/src/main/webapp/images/bitbucket-logo.svg[icon,20,20], for "Multibranch Pipeline", for Single Repository image:/src/main/webapp/images/bitbucket-repository-git.svg[icon,20,20] and Folder image:/src/main/webapp/images/bitbucket-scmnavigator.svg[icon,20,20] project type. This is the default behaviour of the plugin starting from version 935.
90
90
It is possible associate the Bitbucket avatar to the project item selecting the "Show Bitbucket avatar images" behaviour in the project configuration.
91
91
92
-
image::images/screenshot-19.png[scaledwidth=90%]
92
+
image::images/screenshot-19.png
93
93
94
94
The supported avatars are:
95
95
@@ -121,26 +121,38 @@ For Bitbucket Data Center only it is possible chose which webhooks implementatio
121
121
122
122
- Plugin implementation relies on the configuration available via specific APIs provided by the https://marketplace.atlassian.com/apps/1215474/post-webhooks-for-bitbucket?tab=overview&hosting=datacenter[Post Webhooks for Bitbucket] plugin itself. To get it worked plugin must be already pre-installed on the server instance. This provider allows custom settings managed by the _ignore committers_ trait. _Note: This specific implementation will be moved to an individual repository as soon as https://issues.jenkins.io/browse/JENKINS-74913[JENKINS-74913] is implemented._
123
123
124
-
image::images/screenshot-14.png[scaledwidth=90%]
124
+
image::images/screenshot-14.png
125
125
126
126
For both Bitbucket _Multibranch Pipelines_ and _Organization folders_ there is an "Override hook management" behavior
127
127
to opt out or adjust system-wide settings.
128
128
129
-
image::images/screenshot-18.png[scaledwidth=90%]
129
+
image::images/screenshot-18.png
130
130
131
131
IMPORTANT: In order to have the auto-registering process working fine the Jenkins base URL must be
132
132
properly configured in _Manage Jenkins_ » _System_
133
133
134
+
=== Webhooks signature
135
+
136
+
Once Jenkins is configured to receive payloads, it will listen for any delivery that's sent to the endpoint you configured. For security reasons, you should only process deliveries from Bitbucket.
137
+
To ensure your self-hosted server only processes deliveries from Bitbucket, you need to:
138
+
* Create a secret token for a webhook
139
+
* Enable hooks signature verification for the chosen Bitbucket Endpoints
140
+
* Select the secret token create at point 1, only _String credentials_ are taken into account.
141
+
142
+
Any incoming webhook payloads from that given endpoint will be validated against the configured token, to verify they are coming from the configured Bitbucket endpoint URL.
143
+
144
+
image::images/screenshot-20.png
145
+
134
146
[id=bitbucket-creds-config]
135
147
== Credentials configuration
136
148
137
149
The plugin (for both _Bitbucket multibranch pipelines_ and _Bitbucket Workspace/Project organization folders_) requires a credential to be configured to scan branches. It will also be the default credential to use when checking out sources.
138
150
139
-
image::images/screenshot-3.png[scaledwidth=90%]
151
+
image::images/screenshot-3.png
140
152
141
153
As the `Checkout Credential` configuration was removed in commit (link:https://github.com/jenkinsci/bitbucket-branch-source-plugin/commit/a4c6bf39b83168ff62fc622bd4084ef90cf810c0[a4c6bf3]), you can alternatively add a `Checkout over SSH` behavior in the configuration of Behaviours, so that to configure a seperate SSH credential for checking out sources.
142
154
143
-
image::images/screenshot-7.png[scaledwidth=90%]
155
+
image::images/screenshot-7.png
144
156
145
157
=== Access Token
146
158
@@ -154,13 +166,13 @@ First, create a new _access token_ in Bitbucket as instructed in one of the foll
154
166
155
167
At least allow _read_ access for repositories. If you want the plugin to install the webhooks, allow _Read and write_ access for Webhooks.
156
168
157
-
image::images/screenshot-16.png[scaledwidth=90%]
169
+
image::images/screenshot-16.png
158
170
159
171
Then create a new _Secret text_ credential in Jenkins, enter the Bitbucket token generated in the previous steps in the _Secret_ field.
160
172
161
173
If you want be able to perform git push operation from CLI than you have to setup _write_ access for repositories. Than configure the _Custom user name/e-mail address_ trait with the Repository Access Token email generated when you created the Repository Access Token (for example, [email protected]).
162
174
163
-
image::images/screenshot-17.png[scaledwidth=90%]
175
+
image::images/screenshot-17.png
164
176
165
177
=== Personal Access Token
166
178
@@ -190,13 +202,13 @@ The plugin can make use of OAuth credentials (Bitbucket Cloud only) instead of t
190
202
First create a new _OAuth consumer_ in Bitbucket as instructed in the https://confluence.atlassian.com/bitbucket/oauth-on-bitbucket-cloud-238027431.html[Bitbucket OAuth Documentation].
191
203
Don't forget to check _This is a private consumer_ and at least allow _read_ access for repositories and pull requests. If you want the plugin to install the webhooks, also allow _read_ and _write_ access for webhooks.
192
204
193
-
image::images/screenshot-10.png[scaledwidth=90%]
205
+
image::images/screenshot-10.png
194
206
195
207
Then create new _Username with password credentials_ in Jenkins, enter the Bitbucket OAuth consumer key in the _Username_ field and the Bitbucket OAuth consumer secret in the _Password_ field.
196
208
197
-
image::images/screenshot-11.png[scaledwidth=90%]
209
+
image::images/screenshot-11.png
198
210
199
-
image::images/screenshot-12.png[scaledwidth=90%]
211
+
image::images/screenshot-12.png
200
212
201
213
[id=bitbucket-mirror-support]
202
214
== Mirror support
@@ -213,14 +225,14 @@ Cloning from the mirror can only be used with native web-hooks since plugin web-
213
225
214
226
For branches and tags, the mirror sync event is used. Thus, at cloning time, the mirror is already synchronized. However, in the case of a pull request event, there is no such guarantee. The plugin optimistically assumes that the mirror is synced and the required commit hashes exist in the mirrored repository at cloning time. If the plugin can't find the required hashes, it falls back to the primary repository.
215
227
216
-
image::images/screenshot-13.png[scaledwidth=90%]
228
+
image::images/screenshot-13.png
217
229
218
230
[id=bitbucket-build-status]
219
231
== Bitbucket build status
220
232
221
233
When a new job build starts, the plugin send notifications to Bitbucket about the build status. An "In progress" notification is sent after complete the git checkout, another notification is sent at the end of the build, the sent value depends by the build result and the configuration given by the trait.
0 commit comments