We are using Jenkins with Pipeline Jobs and of course the awesome Jenkinsfile.
Twice now a developer accidentally clicked on the build button, which ended up causing a bit of chaos. I am trying to figure out if it is possible to have something like a popup that asks "Do you really want to start this build?".
Any ideas on this user related issue are welcome.
Have a look at the article Controlling the Flow with Stage, Lock, and Milestone in the Jenkins blog, which covers a bit more than only asking for confirmation.
Essentially, there is the input step, which requires user input to continue pipeline execution.
The problem with the input step as suggested by StephenKing is that you won't be able to run the build automatically anymore as it will always ask for the user to confirm the input step manually. This prevents "automatic builds" triggered e.g. by webhooks or CRON jobs.
One workaround is to have a timeout and the build is triggered if the timeout is over. Like that, a user can at least abort an unintended build. But this leads to significantly longer build times.
What we did in my old company was, that we created a so called "parametrized" build, which had a simple checkbox "Do you really want to build this job" that resulted in a flag REALLY_BUILD as an environment variable. You can then ask for ${REALLY_BUILD}==1 in the Jenkinsfile. Every time a developer triggers a build, he has to check the box, otherwise the build will not start / immediately stop.
When you trigger your job via a webhook, you can pass a parameter REALLY_BUILD as an URL parameter (see this comment in the Jenkins tracker) and access it in the Jenkinsfile as before.
Here is another resource for how to use parameters in Pipelines.
Related
I am switching from the github pull request builder plugin (for security reasons) and am trying to get the same functionality from Pipelines (using different plugin). I think I have just about everything, however I can't seem to find a way to re-trigger a build simply by a trigger phrase like in github pull request builder plugin. Is that possible via pipelines?
By trigger phrase, I mean that a user can make a comment on the PR saying "Jenkins re-test" and it will kick off the build again.
You can put a condition at the top of the build script to check for the message. You can access the changesets using currentBuild.ChangeSets. The last changeset is at the end of the array. Then you need to access the last element of that changeset. Finally you can access the message via message property. You can then search for your keyword.
I am doing the opposite (not triggering the build with a phrase) but never tried for pullrequests though.
Another idea is to use the "ignore builds with specific message" property and setting this message to be a regex with look ahead that accepts everything except the keyword. I don't really recall the syntax though :/
I was able to create the new job but I am NOT able to add any build step.
This behaviour is reproducible and it occurs when I try to do it from the initial “configure” page I get after job creation as well as with a later configure attempt. And its persists for all job types.
It does not depend on whether I am logged in or not.
The problem is that when I open the “add build step” I get a selection of possible job types (“shell script”, “windows batch”, …) but when I select one of those nothing more happens.
I also have other jobs of this type already up and running and I am also not able to add more build steps to those.
I had this with v1.625.3, all of a sudden. Problem in Chrome and FF. Workaround was to use IE.
The issue here is once the first Job in a Jenkins pipeline is done, we need to ask some inputs from user and based on the user Inputs to decide the next job to be triggered(Job2 or Job3)
tried build flow and parameterzied trigger plugin but didn't find any suitable option under these.
Any other plugin or jenkins feature which can help in achieving the above scenario?
There are a few plugins I have tried which collect user input on manually triggered jobs in a build pipeline: Active Choices Plug-in 1.2 and Extensible Choice Parameter 1.3.2.
With Active Choices you define a list of selections and a default value. With Extensible Choice Parameter you can have a text box and a default value.
This is how they work for me in Build Pipeline 1.4.8 on jenkins 1.628
If you run the manual step directly in the pipeline the default is used and other parameters propagate through correctly.
If you open the step there is an option to Build with Parameters which will ask for the user input. This works but other parameters like the build number do not propagate through so the pipeline is broken, and the pipeline screen does not show the status.
Jenkins will never pause and ask a user for inputs. It is an automated build system. It doesn't expect anyone sitting at the console watching the progress.
You can provide "inputs" or parameters when you manually trigger the job, i.e on the first job in your pipeline. You can them pass these parameters to downstream jobs, either through the Parameterized Trigger plugin or through a file copied between jobs.
If you need a human decision in the middle of your build flow, consider Promoted Builds plugin. With this plugin, a human can select a build, and then decide which "Promotion" to execute (which could branch your workflow as you need). The promotions can also be automated if needed, based on criteria and not human input.
Is there a way to restrict a build step for a user. I have added a build step using the templates plugin, this template is for the deployment.
I do not want any users who has access to create a job or modify a job to be able to use this build step. The new build step that has been added should only be used by the the administrator.
If people can modifying Job configuration, they can get around any limitation you would place.
If your step can be executed post-build, I suggest to take a look at Promoted Builds plugin. The promotions can be configured to be limited to certain users only. But again, if a user has ability to change job configuration, they can overcome that easily.
The only way I can think of, is to have an external script (or preferably a compiled program than cannot be simply "read" with text editor) that is expecting a password that only you now, before executing whatever secret stuff that you want.
I have several Jenkins jobs where I want an email to be triggered (or not trigger) based on an input parameter.
The use case is that I have one deploy job per project, but that job is parametrized for each environment. We you run the job you can select which environment to deploy to (Dev1, Dev2, QA, etc). Ideally I would like to send out notification emails when a new build is sent to QA, but I do not want to send out notification emails when a new build is sent to Dev, because that happens all the time (with every developer commit) and would flood email boxes.
I've tried googling but haven't yet found a solution. I am currently using the email-ext plugin.
Thanks.
It is a very nasty way to solve the problem, but if you cannot do it by any other means...
Create a dependent job that exists primarily to pass / fail based on the value of the parameter, which would get passed as a parameter to the job. Then you could chain the decision the job made to the email notification.
Of course, if you were going to do this, it would probably be better to just write a small parametrized email sender using javax.mail and have Jenkins run it by "building" an ANT project that actually calls the "java" task. Then you have your own email sender (full control) and could make it a dependent job on the other tasks.
I hope someone chimes in with a simpler way...
In email-ext you can add a "Script - Before Build" or a "Script - After Build" trigger which will trigger on whether the specified groovy script returns true or false.
The help for the script reads:
Use this area to implement your own trigger logic in groovy. The last line will be evaluated as a boolean to determine if the trigger should cause an email to be sent or now.
They don't give many details of what's available in the script, but from the source code on Github, it looks like you have "build" and "project" at least, and some common imports done for you:
cc.addCompilationCustomizers(new ImportCustomizer().addStarImports(
"jenkins",
"jenkins.model",
"hudson",
"hudson.model"));
Binding binding = new Binding();
binding.setVariable("build", build);
binding.setVariable("project", build.getParent());
binding.setVariable("rooturl", JenkinsLocationConfiguration.get().getUrl());
binding.setVariable("out", listener.getLogger());
Caveat, I haven't tried this, but this should work as an example script:
build.buildVariables.get("MY_DEPLOYMENT_ENV") == "QA"
that should get the value of a String or Choice parameter you've created called "MY_DEPLOYMENT_ENV" and trigger the email if the current value is "QA"