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,
)
Related
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 CI jenkins platform and we want to manage our deployments with an email confirmation. A user send a request to the deployment plan for starting. But in the first step, the plan send an email confirmation to an administrator. If the admin click the request link, deployment will be start, otherwise wont start.
Is there a way to do this with jenkins or any jenkins plugin?
yes there is a way to do that, honestly, more than one way to do that and you can choose by your preferneces. What I will suggest you is to consider the way explained in the issues of Jenkins https://issues.jenkins-ci.org/browse/JENKINS-33793
though it have status Unresolved, but it looks like by my knowledge that it will work even right now , cause it is just an URL.
I've been reading a few articles and watching a few videos on Jenkins. I'm wondering how easy it would be once the master branch has been deployed to a staging server to automatically send an email to the client notifying them of the url to the staging server and also giving them a link to "deploy live". This way the client can see the changes, make sure they're happy with it then deploy it themselves without having to email anyone requesting it to go live.
Anyone got any idea how easy this would be to do with Jenkins? There may be a plugin that does this but so far I've not come across anything.
I saw a talk where a guy does this to notify QA of a new build to test, as well as notify when a build is ready to be published to production.
Basically the last automated job (deploy to staging job) has a post build step to send an email to some address. The body of the email contains a link back to the REST API for the "deploy to production" job, triggering a build.
Email recipient tests things, and if satisfied, clicks the link and Jenkins runs the production job. Obviously this requires that the recipient has some kind of access to (at the very least, the REST API of) the Jenkins instance. That being said, there's no reason you couldn't set up your own system to take limited external requests and forward them to your Jenkins API.
The video link (including time reference of the relevant part) is: https://youtu.be/3HI7mv_791k?t=3169
If you've been watching a few videos you might have already come across it, but it's quite long so you might not have watched it all.
Similar to this question How can we execute Jenkins job using other user credential
I have users who will login to Jenkins using active-directory credentials, and then as part of the job use publish-over-cifs, which must use the same domain credentials they supplied when logging in.
This would require that Jenkins retains the password in memory in order to provide it to the cifs plugin.
How should I do this?
I've added a Jenkins Issue https://issues.jenkins-ci.org/browse/JENKINS-22561?focusedCommentId=198490#comment-198490 sponsored for $25 https://freedomsponsors.org/core/issue/483/publish-over-cifs-should-be-able-to-use-jenkins-session-credentials-including-domain-when-jenkins-active-directory-authentication-is-used?alert=SPONSOR#
I am sorry, I don't know how to answer your question, but here is a completely off-the-wall hypothetical solution.
The AD user, on their own machine, is already logged in and can use the AD shares/SMB with their logged in credentials.
Design a job that asks the user for the IP address of their machine. Then have the job spawn a Jenkins Slave on that machine, and execute the job on that Slave, so that it inherently gets access to AD.
This answer probably deserves a downvote
Is there a simple way of accessing the Jenkins API key (as described by Authenticating scripted clients) of the user that invoked the script? I'm looking to pass it into the build script so that it can perform some maintenance operations back on Jenkins.
Since I never found one, I can say that it's safe to say that (as of May '12, at least) there isn't one.