The projects concerned in my linked solution are the initialise database, import database and export database.
If the initialisation succeeds then 'export' should be called. If it fails then 'import' should be called.
dbinit
/ \
export import
Logically this is simple enough; however, due to my lack of Jenkins experience, it's causing considerable grief.
I've looked at the following plugins:
Conditional BuildStep - this basically adds an 'if' statement to the build. I investigated this with the idea that the export/import projects can be collaborated into one project, using the condition to decide which course of action to take. This could work if I was able to check the condition of the upstream build (success or failure)
Post Build Task - executes a shell script based on the log output. This would go in the dbinit project. The problem with this is that I would like import/export jobs to be separated from dbinit. This would work IF I could call another job from the shell
Parameterized Trigger - This could be perfect. This would basically solve the problem by deciding which job to run based on the status of that build. However, at the time of writing, this plugin does not perform correctly with Jenkins version 1.481 or above. This problem was raised a month ago (see error link, dated the 12th Sep 2012) and has still not been fixed, therefore I am still looking for another solution.
Can anyone tell me how to overcome the identified problems with any of these plugins?
Or is there another route that I've overlooked?
Many Thanks,
Rory
In case jenkins 1.481 or later doesn't give you anything you need, and Parametrized Trigger works, then simply use 1.480, and wait 'till problem gets fixed (it is sure to get fixed, that's so popular plugin).
Would the Build Result Trigger help you?
With the BuildResultPlugin, you configure jobB to monitor jobA build result. A build is scheduled if there is a new build result matches your criteria (unstable, failure, ...)
Related
I have a stage which checks whether any hardcoded credentials aren't going into the build.
This is done using a custom jenkins library.
Now, there are many pipelines in which I need to add, so I figured out two solutions :
Make a python script and manually figure out the text pattern in each/most of these Jenkinsfiles where I can add my stage.
Let Jenkins do the work of checking whether the stage exists and if not fail the build, so that the developer could herself/himself add the stage.
Now, 2nd is the one I would like to go with as it's quite scalable ( so to say ) and I don't have to go with the unreliableness of pattern searching to add the stage using python and moreover I already have tried out the 1st one.
This question is similar to this : jenkins-making-a-build-fail-if-javadoc-is-missing
In the above question, the solution seeker wishes to fail the build based on javadoc string.
The solution as suggested is a plugin, but I don't want to increase the complexity to this solution because for this I will have to learn plugin development for Jenkins and seeing that it's in JAVA, it will take even more time ( I am fluent in Python ).
I have worked, rather struggled with groovy to make a Jenkin libs, but I am ready to walk that path, if need be.
Thanks.
Just thinking if you could introduce some kind of global variable in your flow which will store all the env.STAGE_NAME at the beginning of each stage (need just one-liner on every stage). At the end of the flow, you validate all the stage names from the list and see if you are missing anything.
I'm slowly replacing traditional jobs with Jenkins pipelines. We've got some jobs which I've previously optimised by only deleting some key files from the workspace of a previous build - thus we end up with incremental builds rather than full ones. FTR this makes our basic builds 3/4 times faster, and I'm keen to preserve it.
I need to delete those files (to simplify real scenario) that contain "cache". I currently use "**/cache" as an include parameter to the Delete Workspace build step. Question: is there something similar already in pipeline steps? I could probably do it using find or similar, but this has to work on Windows too and that has portability implications.
You could use the cleanWS step to clean up certain parts of the workspace. However, it is a plugin you can find here: Workspace Cleanup Plugin.
You can find syntax about a snippet generator for this step at your-jenkins-url/pipeline-syntax/
I've switched away from using cleanWS having used it. Rather I am using the file operations to explicitly delete the files concerned.
The file operations act there and then. The cleanWs acts at the end of a run and can't be relied upon if that run went wrong and did not finish - e.g. syntax error - or that was running a different script.
I have a plugin in Jenkins for Checkmarx which scans the source code for static code analysis. Is there to make that plugin be compulsory for every job in jenkins?
For that matter any plugin.
The answer, that you probably don't want to hear, is: No.
The only way you can enforce something to happen at all times, is by writing your own plugin for your own "Project type" (instead of Maven or Free-style), and then enforce that everyone uses your project type.
Found a implicit way to do it.
Using jenkins rest api(batch,python,ruby) - run through all job
config.xml.
Download the jobConfig.xml
Update the xml with the plugin(checkmarx in this case) config
Upload(POST) it back to jenkins server.
Run this on a schedule and it shall force everyone to use it.
As I said its an implicit way of doing it.
Checkmarx plugin provides a build step, so it will run every time the job runs. No need to force, if I understand the question correctly. Just make sure the "Skip scan if triggered by SCM Changes" flag is unchecked, which is the default. See more info about the plugin here: https://checkmarx.atlassian.net/wiki/display/KC/Configuring+a+Scan+Action
Downloading the config.xml for the job and posting it back is a bad idea for several reasons. First checkmarx does not require the code to be compiled so you are wasting precious cycles on a build slave. Second Jenkins jobs can do more than compile and they could deploy to production accidentally. Just don't do it. The best way to do what you want to do is to download the config.xml file and then extract the repository url. You can use the Checkmarx rest api to perform a scan. You can probably name the program in checkmarx in some way to relate it back to the jenkins job.
I've got a job that runs for a long time (for example, it builds few solutions), Is there a way to know the current solution that is beind compiled on runtine?
I mean, the Log is very long, so sometimes is confusing to know what is the current compilation that is running.
I want to know what is the current solution that is being compiled now...
Any plugin or a way to do that?
It would be easier to diagnose problems if you split the job into multiple jobs (each one building a single solution). If you have dependencies between the different builds (i.e. one part of the build cannot happen until another part has completed), you can create a build pipeline, where once one job finishes, it triggers the next job in the pipeline. You can do this using the post-build action Build other projects in the job configuration.
There is also an excellent build pipeline plugin which helps you visualize your build pipeline.
If it is the case that you must have the whole solution built in a single job, then one approach would be to use the Jenkins log parser plugin to display a cut-down version of your build log, which just highlights the key events you are interested in to diagnose such problems.
More details of this plugin can be found at:
https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin
I've got two ideas for a possible solution but they needed to be implemented:
1. Adding a prefix for each row in the Log. The prefix could be a string.
for example, if there was a new Project Compilation started then the Log finds the line
----- Rebuild All started: Project: PROJ1 , Configuration: Release x64 ------
Then it adds all the rows after it the prefix "Building PROJ1"
until the log reads the next project:
----- Rebuild All started: Project: PROJ2 , Configuration: Release x64 ------
2. Adding a the current project name that's building to the flashing Job status blue ball.
I mean, finding the current building project from the Log, then adding it next to the current job status (the flickering ball).
Is it possible to set the build result for a build after that build is complete?
I could not find any plugins that do this already, and I was considering writing my own, but I wanted to see if this was even possible before going down that path.
(I have looked at existing code and how the "Fail The Build" plugin works as an example, but my understanding of the Jenkins code base is not advanced enough to understand what all the possibilities are.)
Use case: we have a build pipeline, and near the end of the pipeline there is a deploy-to-qa step that deploys the artifact to a QA environment. We have automated tests before this step to try to catch any problems with the artifact, but our test coverage is not very high in some areas so bugs could still slip through the cracks. I'd like to have the ability to mark a deploy-to-qa build as FAILED after the fact, to denote that that particular pipeline was invalid and is not a candidate for production release. (Basically the same as this Build Pipeline Plugin issue)
After some more investigation in the code, I believe that this is not possible.
From hudson.model.Run:
public void setResult(Result r) {
// state can change only when we are building
assert state==State.BUILDING;
// snip
...
}
So the build result cannot change except when in "building" state.
I could try to muck with the lastSuccessful and lastStable symlinks (as is done with the delete() function in hudson.model.AbstractBuild), but then those would be reset as soon as Jenkins reloaded the build results from jobs/JOBNAME/builds/.
I have an untested suggestion: Make a parametrized build, where the parameter determines if build will fail or not (for example simple bat / shell script testing the parameter from the environment variable it sets, and doing exit 0 or exit 1). This assumes that build pipelines manually triggered step will ask the parameters, and not use default values.
If it does not support interactive build parameters, then some other way is needed to tell this extra build step wether it should fail or not. Maybe editing upstream build description or display name to indicate failure, and then allowing build pipeline to continue to this extra build step, which probably has to use system groovy script to dig out upstream build description or display name.
I have seen several debates on this topic previously, and the outcome was always that it is theoretically possible to do so, but the codebase is not designed to allow this and it would have to be a very hacky workaround.
It's also been said that this is a bad practice in general, although I don't remember what the argument against it was.
I am facing the same requirement. I haven't found an appropriate plugin, changing the build status is not just a flag but has other impacts on links (eg latest successful build etc). So instead of changing the status of the build I looked for a possibility for qualifying the build. The Promoted Builds Plugin apply flags to build to define e.g. different quality stages. Build promotions can be performed manually or based on e.g. downstream project successful builds. Any successful build can be qualified, based on the promotion additional build and post build actions can be executed, e.g tagging or archiving.
Actually I was able to do it by changing the build.xml manually to <result>FAILURE</result>.
I've then played a little bit with mklink to create some symbolic links and also renamed the lastSuccessfulBuild to lastFailedBuild and it worked. If you are allowed to access the filesystem from within a Jenkins PlugIn, then it is possible to write one.
In case you are fine to delete the current build and start the same build using a version number and setting the next BUILD_NUMBER to the deleted one, then you could use this plugin to tell it to fail instead of succeed:
Fail The Build Plugin