-
Bug
-
Resolution: Fixed
-
Major
-
None
-
OS: 16.04.6 LTS 4.4.0-1081-aws
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b03)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b03, mixed mode)
Jenkins ver. 2.150.2
GitHub plugin 1.29.4
GitHub Branch Source Plugin 2.5.1
Jenkins is accessed through reverse proxy (nginx via proxy_pass).OS: 16.04.6 LTS 4.4.0-1081-aws OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b03) OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b03, mixed mode) Jenkins ver. 2.150.2 GitHub plugin 1.29.4 GitHub Branch Source Plugin 2.5.1 Jenkins is accessed through reverse proxy (nginx via proxy_pass).
-
-
branch-api-plugin-2.6.0
Occasionally, a push to a branch triggers two builds on the corresponding branch in a multibranch pipeline. We are using the GitHub as branch source, and have added a organization wide GitHub webhook on push only. I am not sure about the relationship between the GitHub plugin and the GitHub branch source plugin.
On normal builds we see the following two lines:
Started by GitHub push by (author)
Push event to branch master at 9:31:27 AM on May 2, 2019
Each of the builds that are triggered twice has just one of the above lines, i.e.
Started by GitHub push by (author)
and
Push event to branch master at 9:31:27 AM on May 2, 2019
respectively.
Can anyone shed light on what these two lines mean?
The Jenkinsfile has this property:
properties([
pipelineTriggers([githubPush()]),
])
Removing it does not seem to have any noticable effect though.
- is related to
-
-
- Resolved
-
-
-
- Closed
-
[JENKINS-57303] Duplicate builds triggered from webhook (push) on branch pipelines
Mads Navntoft Noe
created issue -
| Link |
New:
This issue is related to |
Mads Navntoft Noe
added a comment - bitwiseman the issues might be related. In our case, the duplicate builds are triggered by a push directly to master, however. Here is a an except from the scan log:
{{[Tue May 07 10:40:30 CEST 2019] Received Push event to branch master in repository unsiloai/frontend UPDATED event from 1.2.3.4 ⇒ http://xxx/github-webhook/ with timestamp Tue May 07 10:40:23 CEST 2019}}
{{ 10:40:30 Connecting to https://api.github.com using XXX}}
{{ Examining xxx/xxxChecking branches...}}
{{Getting remote branch master...}}
{{Checking branch master}}
{}{{Getting remote pull requests from branch master...}}
'Jenkinsfile’ found
Met criteria
{{ Changes detected: master (1d0d76c990ceba060b8e1eda5385e1c0303caf62 → 9c27cad8317b545cae40ea3bda7f637061055000)}}
{{ Scheduled build for branch: master1 branches were processed (query completed)}}
{}{{1 branches were processed}}
{}{{Finished examining xxx/xxx}}
{{{{}}{{[Tue May 07 10:40:37 CEST 2019] Push event to branch master in repository xxx/xxx }}}}
{{UPDATED event from 1.2.3.4 ⇒ http://xxx/github-webhook/ with timestamp Tue May 07 10:40:23 CEST 2019 processed in 6.8 sec}}
We will try to remove the PR specific behavior as seen in the screenshot, and report whether the problem persists. If not, it could be related to the PR discovery part.
Mads Navntoft Noe
added a comment - bitwiseman the issues might be related. In our case, the duplicate builds are triggered by a push directly to master , however. Here is a an except from the scan log:
{{ [Tue May 07 10:40:30 CEST 2019] Received Push event to branch master in repository unsiloai/frontend UPDATED event from 1.2.3.4 ⇒ http://xxx/github-webhook/ with timestamp Tue May 07 10:40:23 CEST 2019 }}
{{ 10:40:30 Connecting to https://api.github.com using XXX }}
{{ Examining xxx/xxx Checking branches... }}
{{ Getting remote branch master... }}
{{ Checking branch master }}
{ }{{Getting remote pull requests from branch master... }}
'Jenkinsfile’ found
Met criteria
{{ Changes detected: master (1d0d76c990ceba060b8e1eda5385e1c0303caf62 → 9c27cad8317b545cae40ea3bda7f637061055000) }}
{{ Scheduled build for branch: master 1 branches were processed (query completed) }}
{ }{{1 branches were processed }}
{ }{{Finished examining xxx/xxx }}
{{{{}}{{ [Tue May 07 10:40:37 CEST 2019] Push event to branch master in repository xxx/xxx }}}}
{{ UPDATED event from 1.2.3.4 ⇒ http://xxx/github-webhook/ with timestamp Tue May 07 10:40:23 CEST 2019 processed in 6.8 sec }}
We will try to remove the PR specific behavior as seen in the screenshot, and report whether the problem persists. If not, it could be related to the PR discovery part. Mads Navntoft Noe
added a comment - Encountered the issue again today, so it does not seem to be related to the PR specific behavior.
Another detail is that we have multiple projects for the same repository (it's a monorepo), and all of them triggered twice this time. Mostly it's just one of them that triggers twice, though.
Mads Navntoft Noe
added a comment - Encountered the issue again today, so it does not seem to be related to the PR specific behavior.
Another detail is that we have multiple projects for the same repository (it's a monorepo), and all of them triggered twice this time. Mostly it's just one of them that triggers twice, though. Trying out a workaround using the property strategy "(Deprecated )Suppress automatic SCM triggering" from the Branch API plugin. This results in the builds only being having the line "Started by GitHub push by (author)". So far there have been no new duplicate builds.
Mads Navntoft Noe
added a comment - - edited Trying out a workaround using the property strategy "(Deprecated )Suppress automatic SCM triggering" from the Branch API plugin. This results in the builds only being having the line "Started by GitHub push by (author)". So far there have been no new duplicate builds. Mads Navntoft Noe
added a comment - Using the "(Deprecated )Suppress automatic SCM triggering" property strategy, new branches are not being built initially. Does anybody have an idea for a workaround for this?
Mads Navntoft Noe
added a comment - Using the "(Deprecated )Suppress automatic SCM triggering" property strategy, new branches are not being built initially. Does anybody have an idea for a workaround for this? mn_unsilo
That is probably expected behavior for that trait. This is probably something that needs to be fixed in the plugin itself.
| Link |
New:
This issue is related to |
mn_unsilo
I believe this issue is mitigated by branch-api-plugin v2.6.0 honoring quiet period for multibranch pipeline jobs child pipelines (JENKINS-54052). I'm resolving this for now.
Please reopen if this issue still occurs after upgrading to branch-api-plugin v2.6.0.
It looks like this is duplicate of
JENKINS-54610. Does that look right to you?