@@ -28,69 +28,29 @@ Ok. Still here?! Then this might be for you :bowtie:
28
28
29
29
  ;
30
30
31
- ### How it works in three sentences
31
+ ### How it works in three sentences and one picture
32
32
33
33
* Plugin REST Endpoint parses the actual GitHub Webhook JSON Payload and extracts its information.
34
34
* It then triggers all Jenkins jobs matching ` {repositoryOwner}---{repositoryName}.* `
35
35
* Lastly it injects Environment Variables into the job run for you to determine what branch and revision is to clone.
36
36
37
-
38
- -----
39
-
40
-   ;
41
-
42
- ### Webhook - The only who tells the truth!
43
-
44
37
![ ] ( https://codeclou.github.io/jenkins-github-webhook-build-trigger-plugin/img/webhook-payload---with-overlays.png?v2 )
45
38
46
39
-----
47
40
48
41
  ;
49
42
50
- ### How to build the plugin
51
-
52
- Jave Oracle Java 8 and Apache Maven 3 installed. And then build like this:
53
-
54
- ``` bash
55
- git clone https://github.com/codeclou/jenkins-github-webhook-build-trigger-plugin.git
56
- cd jenkins-github-webhook-build-trigger-plugin
57
- mvn clean
58
- mvn compile
59
- mvn hpi:hpi
60
- ```
61
-
62
- Now you should have a file called ` ./target/github-webhook-notifier-plugin.hpi ` which
63
- you can upload manually to Jenkins under 'Manage Plugins' → 'Advanced' → 'Upload Plugin'.
64
-
65
- -----
66
-
67
-   ;
68
-
69
- ### Why?
70
-
71
- I needed something that forcefully triggers my Jenkins Jobs by passing the actual Git Commit ID.
72
-
73
- The default behaviour of existing plugins is to "decide if it needs to rebuild". Which leads
74
- to a state where if your job just build your ` master ` Branch and you create a tag of off the ` master ` branch
75
- and push that tag, that the jenkins job will not be triggered, since the revisions are equal.
76
-
77
-
78
- ### NOTE
79
-
80
- When using matrix-based security the 'Anonymous' user needs 'Job' ` build,discover,read ` rights.
81
-
82
-
83
-
84
-
85
43
### GitHub Webhook Configuration
86
44
87
45
* ** Payload URL**
88
- * ` https://jenkins.foo/jenkins/github-webhook-build-trigger/receive `
89
- * Note: The endpoint can be called without authentication.
46
+ * ` https://jenkins/github-webhook-build-trigger/receive `
47
+ * Note:
48
+ * The endpoint can be called without authentication.
49
+ * When using matrix-based security 'Anonymous' needs 'Job' → ` build,discover,read ` permissions.
90
50
* ** Content type**
91
51
* ` application/json `
92
52
* ** Secret**
93
- * Choose a good secret, at best a random sha512 hash
53
+ * Choose a good secret, at best a random sha512 hash. Use that secret for all webhooks of all your repositories.
94
54
* ** Which events ...**
95
55
* Just the ` push ` event
96
56
@@ -117,6 +77,53 @@ And that triggers this exact id for the exact branch/tag that has been sent by t
117
77
118
78
119
79
80
+
81
+ -----
82
+
83
+   ;
84
+
85
+ ### Appendix
86
+
87
+ ** Build Plugin**
88
+
89
+ Jave Oracle Java 8 and Apache Maven 3 installed. And then build like this:
90
+
91
+ ``` bash
92
+ git clone https://github.com/codeclou/jenkins-github-webhook-build-trigger-plugin.git
93
+ cd jenkins-github-webhook-build-trigger-plugin
94
+ mvn clean
95
+ mvn compile
96
+ mvn hpi:hpi
97
+ ```
98
+
99
+ Now you should have a file called ` ./target/github-webhook-notifier-plugin.hpi ` which
100
+ you can upload manually to Jenkins under 'Manage Plugins' → 'Advanced' → 'Upload Plugin'.
101
+
102
+
103
+   ;
104
+
105
+   ;
106
+
107
+ ** What's the story behind it?**
108
+
109
+ I needed something that forcefully triggers my Jenkins Jobs by passing the actual git revision and branch or tag information.
110
+
111
+ The default behaviour of existing plugins is to receive the GitHub Webhook Payload, but
112
+ only using the ` after ` commit id and "deciding if it needs to rebuild the job".
113
+
114
+ Example: You are on your ` master ` Branch and you create a tag of off the ` master ` branch
115
+ and called ` 1.0.0 ` . When pushing ` 1.0.0 ` tag, the jenkins job will not trigger an actual build.
116
+ What happens? It will do some strange ` git fetch ` requests and comes to the result, that the revision
117
+ was already built with the previous push done by ` master ` branch. And partly he is right.
118
+ Until further commits happen, the ` master ` branch has the same revision as the ` 1.0.0 ` tag.
119
+ But ** I want tag pushes to trigger a build anyway** . And since I hate 'API-wrappers' of stuff,
120
+ I decided to create a single purpose tool that just passes the information of the webhook payload
121
+ through to the job. And it is the jobs logic that can now decide what to do.
122
+
123
+
124
+   ;
125
+
126
+
120
127
-----
121
128
122
129
  ;
0 commit comments