I would like to use Replay feature. The documentation said:
1) Can be called multiple times on the same run
2) Can also be called on Pipeline runs that are still in-progress
What is the difference with these two points? Could you explain me better?
1) Each 'Build' (or 'Run') has some configuration (like parameters of the build for 'Build with parameters') that sometime you want to reuse in Replay. You can launch multiple Replay on the same 'Build'. Each of the Replayed Build will get the same parameters as the original one.
2) You are able to launch Replay also on the 'Build' that is still in-progress. It is irrelevant for Replayed 'Build' because once launched, the original 'Build' already updated its object in Jenkins master with all that will be of use for Replay.
Related
Developer team needs a pipeline should only be allowed to start only if another related pipeline has completed and they need the pipeline view on same page
It is something like this , a set of stages complete and the next stages would start when project manager starts the pipeline manually .
Simply they need to visualize both pipelines in a single page like below picture.
(https://puppet.com/sites/default/files/2016-09/puppet_continuous_diagram.gif)
You can use the step build job: '<first_pipeline>', parameters: [...] in say, stage 1 of your second pipeline as a upstream job. Then define the steps of your second pipeline from stage 2 onwards. This will make sure that the first pipeline is always built when you trigger the second and also works with delivery pipeline view for single page visualization.
Or, if you just want to check if the first pipeline is completed without actually triggering it, use the api <jenkins_url>/job/<first_pipeline>/lastBuild/api/json in stage 1 of your second pipeline with a while loop to wait until the status is “completed”.
I haven't heard of a way to link them, but you could write the steps in the same pipeline.
You can work with input steps to ask for the project manager to confirm. Note that this halts an entire build processor until confirmed (or you set a timeout).
You might also want to have a look at conditional steps.
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.
I am using a Pipeline job to trigger several freestyle jobs during its execution, using the native 'build' step.
Later, after all the runs are finalized, I'd like to read info about those runs (name, number, duration, timestamp...) to collect metrics/stats regarding the overall runs.
I'm using the Groovy Event Listener plugin for that task.
Now, I was thinking to read the WorkflowRun object's actions (looking for BuildTriggerAction instances) to get the downstream builds, but they are not available.
run.getActions(BuildTriggerAction.class)
returns an empty list.
I've seen indeed that action is removed every time the triggered build is completed, as described in this ticket https://issues.jenkins-ci.org/browse/JENKINS-28673
My questions are:
do you know how to retrieve the handle to the triggered builds in another way? Not at runtime (I don't have the RunWrapper object, but the WorkflowRun instead). Maybe using the flow objects?
is there another way to fix the issues seen in the ticket, instead of removing the BuildTriggerAction actions?
Thanks in advance!
I have a Jenkins job that should not start building until another job has been built successfully at least once. They are not related per se, so I don't want to use triggers. Is there a way to do this?
Some background: I'm using SCM polling to trigger the second job. I've looked at the Files Found Trigger plugin, but that would keep on triggering the second job after the first on has been built. I've also found the Run Condition Plugin, but that seems to work only on build steps, not on the entire build.
Update - The second job copies artifacts from the first job. As long as the first job has never completed successfully, the Copy Artifact step fails. I am trying to prevent that failure, by not even attempting to build the second job until the first job has completed once.
One solution is to use the Build Flow plugin.
You can create a new flow job and use this DSL:
I've used 10 in the retry section but you can use any numbers.
This flow job can be triggered by monitoring the same SCM URL of your second job.
Update, here is a second solution.
You can use the HTTP Request plugin.
If you want to test that your first job has been built successfully at least once, you can test this URL:
http://your.jenkins.instance/job/your.job/lastSuccessfulBuild/
One example:
As my build has never been successful, the lastSuccessfulBuild URL doesn't exist. The HTTP Request changes my build status to failure.
Does it help?
The Block queued job plugin can be used for this: https://wiki.jenkins-ci.org/display/JENKINS/Block+queued+job+plugin
I had a request a to create a java client and start jenkins build for a specific job; and get back the result of that build.
The problem is, the system is used by multiple users and their build might messed up altogether. Also the get latest build my retrieve me the previous finished build instead of current one. Is there anyway to do build/get result transactionally?
I don't think there's a way to get true transactional functionality (in the way that, say, Postgres is transactional), however, I think you can prevent collisions amongst multiple users by doing the following:
Have your build wrapped around a script (bash, Python, or similar) which takes out an exclusive lock on a semfile before the build and releases it after its done. That is, a file which serves as a semaphore that the build process must be able to exclusively lock in order to be able to proceed.
That way, if you have a build in progress, and another user triggers one, the in-progress build will have the semfile locked, and the 2nd one will block waiting for the exclusive lock on that file, getting the lock only once the 1st build is complete and has released the lock on the file.
Also, to be able to refer to each remote build after the fact, I would recommend you refer to my previous post Retrieve id of remotely triggered jenkins job.