-
Bug
-
Resolution: Cannot Reproduce
-
Blocker
-
IMAGE：jenkins/jenkins:2.336，Git：4.11.5，Generic Webhook Trigger Plugin：1.84，CentOS Linux release 7.4.1708 (Core)
Complete environment version information：
Problem description：
Webhook push data too long, caused pipeline git pull errror. it tips that Argument list too long.
At present, on the gitlab hook, the length of the message text pushed is 1,301,714. The hook can normally trigger the operation of the pipeline. However, when the user-defined shared library code is pulled in the first step, the pull fails. The exception message is caused by: java.io IOException: error=7, Argument list too long.
I infer that the message data pushed by webhook was passed into the GIT command as a parameter, resulting in the execution of the GIT command exceeding the page limit of the Linux command line parameter (MAX_ARG_PAGES).
If I use a small gitlab text hook data, such as 1000 in length, GIT pull will pull the shared library code successfully.
The pipeline log (consoleText.txt) that I have uploaded to the attachment.
Problem Recurrence Procedure：
The first step. Create a new pipeline (not multi-branched) and use Git to pull up the Jenkinfile file.
And the Jenkinsfile file uses this service-biz-ebank.jenkinsfile
. This uses the Jenkins shared Library @library (['jenkinslib-tools@master']) _
The second step. Use Postman for debugging. The POST interface of the hook with large text has been exported. And modify the appropriate token for push debugging.
And the postman file uses this Jenkins webhook git Argument list too long.postman_collection.json . Import the file to Postman and use it
The third step. 使用postman工具推送后，就会出现以下日志的错误：java.io IOException: error=7, Argument list too long.
If you replace the text data in the Body with this smaller data packet: smaller text data.json, The pipeline pulls the Jenkins shared Library @library (['jenkinslib-tools@master']) _ successfully. And the pipeline is also running normally, no abnormalities reported
Pipeline complete log：
Key Log screenshots：
Webhook data size：
[JENKINS-69423] Webhook push data too long, caused pipeline git pull errror. it tips that Argument list too long.
| Attachment | New: image-2022-08-24-17-58-44-307.png [ 58835 ] | |
| Description |
Original:
Webhook push data too long, caused pipeline git pull errror. it tips that Argument list too long.
!image-2022-08-24-17-55-19-305.png! !image-2022-08-24-17-55-43-181.png! |
New:
Webhook push data too long, caused pipeline git pull errror. it tips that Argument list too long.
!image-2022-08-24-17-55-19-305.png! !image-2022-08-24-17-55-43-181.png! !image-2022-08-24-17-58-44-307.png! |
| Description |
Original:
Webhook push data too long, caused pipeline git pull errror. it tips that Argument list too long.
!image-2022-08-24-17-55-19-305.png! !image-2022-08-24-17-55-43-181.png! !image-2022-08-24-17-58-44-307.png! |
New:
Webhook push data too long, caused pipeline git pull errror. it tips that Argument list too long.
At present, on the gitlab hook, the length of the message text pushed is 1301714. The hook can normally trigger the operation of the pipeline. However, when the user-defined shared library code is pulled in the first step, the pull fails. The exception message is caused by: java.io IOException: error=7, Argument list too long. I infer that the message data pushed by webhook was passed into the GIT command as a parameter, resulting in the execution of the GIT command exceeding the page limit of the Linux command line parameter (max_arg_pages). If I use a small gitlab text hook data, such as 1000 in length, GIT pull will pull the shared library code successfully. !image-2022-08-24-17-55-19-305.png! !image-2022-08-24-17-55-43-181.png! !image-2022-08-24-17-58-44-307.png! |
| Description |
Original:
Webhook push data too long, caused pipeline git pull errror. it tips that Argument list too long.
At present, on the gitlab hook, the length of the message text pushed is 1301714. The hook can normally trigger the operation of the pipeline. However, when the user-defined shared library code is pulled in the first step, the pull fails. The exception message is caused by: java.io IOException: error=7, Argument list too long. I infer that the message data pushed by webhook was passed into the GIT command as a parameter, resulting in the execution of the GIT command exceeding the page limit of the Linux command line parameter (max_arg_pages). If I use a small gitlab text hook data, such as 1000 in length, GIT pull will pull the shared library code successfully. !image-2022-08-24-17-55-19-305.png! !image-2022-08-24-17-55-43-181.png! !image-2022-08-24-17-58-44-307.png! |
New:
Webhook push data too long, caused pipeline git pull errror. it tips that Argument list too long.
At present, on the gitlab hook, the length of the message text pushed is 1,301,714. The hook can normally trigger the operation of the pipeline. However, when the user-defined shared library code is pulled in the first step, the pull fails. The exception message is caused by: java.io IOException: error=7, Argument list too long. I infer that the message data pushed by webhook was passed into the GIT command as a parameter, resulting in the execution of the GIT command exceeding the page limit of the Linux command line parameter (max_arg_pages). If I use a small gitlab text hook data, such as 1000 in length, GIT pull will pull the shared library code successfully. !image-2022-08-24-17-55-19-305.png! !image-2022-08-24-17-55-43-181.png! !image-2022-08-24-17-58-44-307.png! |
| Assignee | Original: Mark Waite [ markewaite ] |
When the hook successfully triggers job construction, why send the hook packet data to the git pull command?
And now it's the @library (" XXX ") that pulls the shared Library code. Why does pulling the shared Library code also need the hook's bounding data as an argument?
Pull THE SHARED LIBRARY CODE, I have SPECIFIED THE BRANCH OF THE SHARED LIBRARY code, there is no need to also need the content of the hook message data as a parameter?
How did this problem come about?
Dear markewaite ,
At present, our application scenario is GitLab Webhook. The feature of GitLab hook is that all change records will be pushed to Jenkins as message content. Once a large number of files need to be changed or the package name of a project needs to be modified in batch, the message content of big text hook will appear, which is unavoidable. You can't simply shorten hook content.
13060851331 I'm not a GitLab Webhook expert. I'm not a direct user of GitLab Webhooks. I don't know the answers to your questions.
Question and answer interactions are usually more successful on the Jenkins community forum https://community.jenkins.io , the Jenkins gitter chat channel https://gitter.im/jenkinsci/jenkins , and the Jenkins user mailing list https://groups.google.com/g/jenkinsci-users . Those locations are read by many more people than read the bug reports on the Jenkins issue tracker.
| Component/s | Original: git-plugin [ 15543 ] |
I don't plan to work on this. Use shorter webhook content