I saw a configuration option that allows tagging every build, but it seems this would just needlessly pollute the tag history. Is there a way in Jenkins to tag a build only once it has been marked as passed?
Absolutely, using the Flexible Publish plugin.
This plugin will allow you to wrap post-build actions in a Run condition.
All this really boils down to is, installing & using that plugin, you can wrap your git publish in a Run condition using the Current build status as it's condition, setting it to only run when the entire build has passed (success).
Related
How is that possible to add Pre-Build actions in Jenkins, exactly like it's Post-Build ?
I've came across Conditional BuildStep, Run Condition and Parameterized Trigger plugins, but can't find out a way to add that.
Sadly there is no real pre-build event because not every pipeline may build something.
You can disable the default checkout by using the option skipDefaultCheckout and manually do the git checkout later using the command checkout scm. I think this is the closes you will get to reach a Pre-Build-Stage.
We have some jenkins pipeline jobs defined with Jenkinsfile's located in bitbucket server, as described here. These builds are parameterized, and we'd like to be able to manually run them with non-default parameters.
The problem is, since the Jenkinsfile isn't checked out until we run it, the first time we run the build the build button is just "Build Now" instead of "Build with Parameters". Currently we are running it once with the default values so that it fails, and then running it again with the "Build with Parameters" button so we can pass in what we want.
Obviously not ideal. What is the right way to do this so we can run it with custom parameters the first time?
This is not possible currently, as they are post-processed they need to be executed in the 1st run before being known to jenkins and being available as 'Build with parameters'. Issue tracked here: https://issues.jenkins-ci.org/browse/JENKINS-41929
There are various ways to handle this,
The first is as you have alluded to, run it automatically/manually and let it fail, though maybe if you could set working defaults so it at least succeeds?
Another option, is to evaluate if this is the first run or not, and if so, execute the Jenkins job skipping all steps and purely processing the parameters.
I'm searching for a way to execute automatically a global configured script BEFORE a Jenkins job will be started.
My use case is, all Jenkins jobs are only allowed to start if a specific environment variable is set.
If a variable is not set, the build should be aborted.
I found the Global Post Plugin https://wiki.jenkins.io/display/JENKINS/Global+Post+Script+Plugin, i only need the oposite what this Plugin does.
Maybe there's another solution?
I needed to chmod my /data/jenkins/.npm and /data/jenkins/.sbt directories before running all my builds.
I could either add a prebuild step to every job (redundant and messy) or I could go under Manage Jenkins -> Configure System.
We have a Cloud -> Amazon EC2 configuration section with "Init script" - you can add what you want to run there on slave startup.
However, if you really want something to run something for every job (not enough to run on jenkins slave startup) then you probably don't want to manually configure it for each job.
I suggest you look into Jenkins DSL as you can define preBuildSteps section on any/all job(s) which can then reference a common snippet (eg. a shell script to run).
Partial Solution:
Take a look at the Global Pre Script plugin. This plugin is less feature-rich than the Global Post Script plugin, but it should do at least a part of what you want. It notably lacks the option to abort the build, but it is able to manipulate parameters or other preconditions that your jobs rely on. You may also be able to submit a PR to add some means of preventing the build from executing.
Some options:
Modify Global Pre Script to be able to cleanly abort the build from groovy.
Change your existing jobs to check for a precondition (manually or via script). This not the most scalable option.
Replace your existing jobs with Pipeline jobs and use Shared Libraries to bottleneck the logic. (This is what I do).
Generate your jobs using the Job DSL Plugin and enforce a pre build step in every generated job. (This is what I also do)
Limitations:
Something to keep in mind for both global plugins: neither plugin provides a proper build step. The groovy code executes on the master.
One use case that neither plugin will handle is a between-job slave cleanup/sanity check.
I have a grails app that depends on a custom grails plugin. In Jenkins, I want the release build for the app to depend on the latest promoted release build of the plugin. So, I thought I'd put a conditional in the BuildConfig.groovy to use an environment variable that has that value. So now I need a way to set an environment variable in Jenkins to the latest build number of that other job. Is there a way to do that?
If you can do the envisioned workflow manually (e.g. going into the main configuration and change a environment variable there), then you should be able to automate it using the Jenkins Command Line Interface. However, you can not directly change an environment variable in one job and read that changed value in another job.
Here is what i am trying to achieve:
We have a SVN repository, but we dont want to promote all the changes we get via svn update!
I want to manually select each artifact and then build it via Jenkins and deploy it.
Any plugin which will allow me to do that? I dont have a simple criteria like exclude *.jar or *.xml but it is purely manual human intervention.
Thanks,
Zoom
What about making a new job with build parameters. One of the parameters could be a svn tag/branch to build/run/use, then have a build step that runs a script. In the script you can do whatever you wish with that svn tag, including a checkout and build.
Or, if you want to use pre-built artifacts from another job, you can specify links to those artifacts in the build parameters or a job name/number and have the script automatically grab them for you.
Many different ways to run a job manually :)