I'm trying to trigger a job from one Jenkins (A) on another one (B). I've installed 2 plugins:
Parameterized Remote Trigger
Build Token Root
My issue is, that I'm able to trigger build on Jenkins (B) using for example curl and token only, which means the Build Token Root plugin is working as expected, but Parameterized Remote Trigger seems to don't respect this.
I probably should mention that I've tried different auth options, Trust All certs, etc.
My Jenkins (A) config:
Logs are the same with and without Build Token Root support enabled.
Logs I'm getting:
I was able to get this working by allowing Anonymous users Overall Read and Job Read access. It appears this is necessary because the Parameterized Remote Trigger plugin attempts to call additional APIs apart from just the /build and /buildWithParameters and those calls are the ones that fail.
It makes sense that, in order to have the default blocking capability, you need to call additional APIs to poll, but even setting blockBuildUntilComplete : false did not fix the issue. Considering that Parameterized Remote Trigger plugin plainly says it "plays well" with the Build Token plugin in its documentation, it really is not an easy feat to make them work together.
In my opinion, using the two together isn't an ideal solution because of the necessity for allowing unauthenticated users to browse your jenkins instance via the ui - I suspect you could (although I haven't tried it) get an API Token for a user with only Overall Read and Job Read access instead of giving all Anonymous Users the rights, but this includes the overhead of managing a user and an API Token, which defeats our primary motivation to use the Build Token plugin in the first place.
We have a lot of jenkins jobs set up as webhook endpoints using Generic Webhook Trigger.
It's mostly working fine. With the token, it's able to find the specific Jenkins job to run for each webhook event.
However occasionally we hit a 404 error with below error message:
{"jobs":null,"message":"Did not find any jobs with GenericTrigger configured! If you are using a
token, you need to pass it like ...trigger/invoke?token=TOKENHERE. If you are not using a token,
you need to authenticate like http://user:passsword#jenkins/generic-webhook... "}
Wondering if there is any reason for this behavior? Is it because of how Generic Webhook Trigger's tokens are mapped, maybe it's getting reset once in a while due to some events? We are hitting a scalability bottleneck due to this issue and would love some insights. Thanks ahead!
This is somewhat similar to Pull request policies - Build expired - How can I run the build again? but looks at the automation side.
Our context: We have pull requests which protect our master branch and each completed pull requests expires the builds of all other pull requests to ensure that the builds of all of the remaining pull requests have to be re-queued and build and test correctly.
Now we have times where we get pull request contention (I am looking at you, end-of-sprint!) in these times we have plenty of pull requests open. While we are working on minimizing the amount, it sometimes just happens.
Is there a plugin or some feature I am missing that actually can trigger all of those expired builds after a PR completes automatically? There is a way to automatically expire all other PR builds, so I would have thought that there is also a way to re-queue them automatically. I know this might trigger a build cascade but I would like to have my PRs always as up-to-date as possible.
Related REST API is not documented, however you can track it by tools such as Fiddler or press F12 in Chrome browser then select Network.
In the pull request page to manually queue the build as mentioned in your question.
For example with my azure devops service, I get below API
Post https://dev.azure.com/patricklu/_apis/Contribution/dataProviders/query/project/a72e1ef5-4921-49c5-9260-e72b7bff977d
Request Body:
{"contributionIds":["ms.vss-code-web.pull-request-detail-policy-data-provider"],"context":{"properties":{"repositoryId":"357893bf-9a1f-4ee4-95d3-c5ceda4f4abc","pullRequestId":12,"policyEvaluationIds":["bca44f9f-268f-4640-aa7e-af5253b3b11e"],"pageSource":{"contributionPaths":["VSS","VSS/Resources","q","knockout","mousetrap","mustache","react","react-dom","react-transition-group","jQueryUI","jquery","OfficeFabric","tslib","#uifabric","VSSUI","ContentRendering","ContentRendering/Resources","TFSUI","TFSUI/Resources","WidgetComponents","WidgetComponents/Resources","Charts","Charts/Resources","TFS","Notifications","Presentation/Scripts/marked","Presentation/Scripts/URI","Presentation/Scripts/punycode","Presentation/Scripts/IPv6","Presentation/Scripts/SecondLevelDomains","highcharts","highcharts/highcharts-more","highcharts/modules/accessibility","highcharts/modules/heatmap","highcharts/modules/funnel","Analytics"],"diagnostics":{"sessionId":"8277adc6-6810-4cf9-b984-10860e90c0b5","activityId":"8277adc6-6810-4cf9-b984-10860e90c0b5","bundlingEnabled":true,"cdnAvailable":true,"cdnEnabled":true,"webPlatformVersion":"M156","serviceVersion":"Dev17.M156.1 (build: AzureDevOps_M156_20190821.17)"},"navigation":{"topMostLevel":8,"area":"","currentController":"Apps","currentAction":"ContributedHub","currentParameters":"12","commandName":"Git.pullrequest","routeId":"ms.vss-code-web.pull-request-review-route","routeTemplates":["{project}/{team}/_git/{GitRepositoryName}/pullrequest/{parameters}","{project}/_git/{GitRepositoryName}/pullrequest/{parameters}","_git/{project}/pullrequest/{parameters}"],"routeValues":{"project":"GITAgile","parameters":"12","controller":"Apps","action":"ContributedHub","vctype":"git","viewname":"pull-request-review"}},"project":{"id":"a72e1ef5-4921-49c5-9260-e72b7bff977d","name":"GITAgile"},"selectedHubGroupId":"ms.vss-code-web.code-hub-group","selectedHubId":"ms.vss-code-web.pull-request-hub","url":"https://dev.azure.com/patricklu/_git/GITAgile/pullrequest/12?_a=overview"},"sourcePage":{"url":"https://dev.azure.com/patricklu/_git/GITAgile/pullrequest/12?_a=overview","routeId":"ms.vss-code-web.pull-request-review-route","routeValues":{"project":"GITAgile","parameters":"12","controller":"Apps","action":"ContributedHub","vctype":"git","viewname":"pull-request-review"}}}}}
As you can see there is some value such as repository ID and pull Request ID. Follow this, you should be able to user API to rerun some builds for a specific Pull Request.
You could use Azure DevOps Services service hooks or Rest API to track pull request completed or not, then use above API call to re-run the build. Hope this helps.
I have an internal requirement to stress gitlab to evaluate its performance serving requests for large sized repos with concurrent commits by many engineers. I am using JMeter to record a flow of committing a file from the UI. On replay, I get a 403 because the csrf token validation fails. I have tried extracting the authenticity_token via Regex but the value getting used as part of the X-CSRF_Token header is different and there is no way for me to extract that value from the preceding response.
For the purposes of my load testing, I want to disable this check in gitlab-rails. Where and how should I go about doing this?
Our CI system uses the python module jenkinsapi to launch test jobs on Jenkins. But it's slow - the time taken to run a single job varies between 10 - 30 seconds. That really bogs the system down.
Our production Jenkins is tied into our corporate LDAP. Hence jenkinsapi requires a username/password. Without a doubt this contributes to the problem. I suspect that each time it runs a job it needs to perform a login on Jenkins. The issue is vastly reduced when I run the setup against my local unsecured instance of Jenkins.
Is there any way to workaround these limitation? Can I speed up the execution of jenkinsapi? Or is there an alternative approach that will work better with a secure Jenkins?
If the LDAP authentication is really the bottleneck, you may be able to get around it by using the user's API token instead of the password on API login. It should be as simple as replacing the password with the API token (available on the user's configuration page in Jenkins) in your scripts.
You can try to use the parameter: lazy=True
server = Jenkins(
JENKINS_HOST,
username=JENKINS_USER,
password=JENKINS_TOKEN,
lazy=True,
)