Say I have a maven2/3 project in jenkins/hudson and BEFORE I run some goals on a maven project configured in the correspoing config.xml file, I want to run a system groovy script (ref. system groovy plugin) during a prestep and interrupt the whole job and set it to SUCCESS if some condition is met (for example say I find something in the log file of the previous job). I DO NOT WANT MAVEN TO START EXECUTING THE GOALS.
I have tried
import hudson.model.*
def thr = Thread.currentThread()
def build = thr?.executable
build.executor.interrupt(hudson.model.Result.SUCCESS)
out.print "HELLO"
But nothing happens, and even "HELLO" is printed in log. But then the build gets ABORTED.
Parsing POMs
Discovered a new module ...
Modules changed, recalculating dependency graph
...
...jdk1.6.0_22/bin/java -Xmx512m -cp ...
<===[JENKINS REMOTING CAPACITY]===>Build was aborted
Thanks for your time.
I do not understand fully, what you want, since you described here some solution, not your exact problem. I know three plugins, which could be useful for your problem as well:
Fail the build plugin lets you set the result of the job, and stops further processing. Any status can be set including success.
Conditional build step plugin lets you define conditions for its child build steps. If the condition is met, the child(ren) will run.
m2 extra build steps - lets you run build steps before or after maven build in a maven job in jenkins. Note, that recently, this plugin is the part of the core jenkins.
So the basic idea is that you could add conditional build step a pre-build step in your job, and the child step could be one fail-the build instance. See the picture below:
Related
I need to exclude a job from pipeline in case my project version is pre-release.
How I know it's a pre-release?
I set the following in the version info file, that all project files and tools use:
version = "1.2.3-pre"
From CI script, I parse the file, extract the version value, and know whether it's a pre-release or not, and can set the result in an environment variable.
The only way I know to exclude a job from pipeline is to use rules, while, I know also from gitlab docs that:
rules are evaluated before any jobs run
before_script also is claimed to be called with the script, i.e. after applying the rules.
I can stop the job, only after it starts from the script itself, based on the version value, but what I need is to extract the job from the pipeline in the first place, so it's not displayed in the pipeline history. Any idea?
Thanks
How do you run (start) your pipeline, and is the information whether "it's a pre-release" already known at this point?
If yes, then you could add a flag like IS_PRERELEASE as a variable to the pipeline, and use that in the rules: section of your job. The drawback is that this will not work with automatic pipelines (triggered by a commit or MR); but you can use this approach with manually triggered pipelines (https://docs.gitlab.com/ee/ci/variables/#override-a-variable-when-running-a-pipeline-manually) or via the API (https://docs.gitlab.com/ee/ci/triggers/#pass-cicd-variables-in-the-api-call).
I am using JHipster 3.4.0 with gradle.
Excuse me for newbie questions.
There are times when I don't trust hot reloads and want to do full clean build.
However, executing 'build' task always lead to running integration tests.
Doing something like
test {
// include '**/*UnitTest*'
// include '**/*IntTest*'
// ignoreFailures true
// reports.html.enabled = false
}
in build.gradle doesn't help.
So how do I skip integration tests for full clean build?
And just to confirm, the task to do full clean build is 'build' right?
Thanks in advance,
Sam
To partially answer my own questions. Just found out the command line
gradle build -x test
will do the trick. But I don't think that answer my question of why comment out test task above doesn't work
The reason why the test are still running, when commenting the includes is, that test task has default values (if you don't overwrite them). So all classes in src/main/test are used as test classes. Your way by passing a command line parameter is the way to go.
I have a groovy script that changes the build result using setResult(hudson.model.Result.SUCCESS).
But I realized that I cannot change the job result to a better result (only to worse ones). If I will change the code to: build.setResult(hudson.model.Result.Unstable), then when the build will be successful the result will be changed (I can see in the Console Output: Build step 'Groovy Postbuild' changed build result to UNSTABLE.)
But I can't update the result to a better one.
Is there any solution?
(The same problem occurs with groovy postbuild) .
EDIT:
I'm using the MultiJob plugin in my main job for running 3 downstream jobs (named job1, job2, job3). And I wrote a groovy script so that the result of the main job will be determine only by the first two downstream jobs (when job1 and job2 are success, and job3 is unstable - I wish to set the main job result to success).
because of the problem mentioned above I can't do it... any ideas?
Thanks.
I believe that this expected behavior with Jenkins. Other methods of changing the build result (such as the Fail The Build plugin) also cannot "improve" the build status, they can only make it worse (success to unstable to failed).
Using Post Build plugin and Groovy System Script, you can change build result with Result.fromString() , for example, setting result to "Unstable":
build.result = hudson.model.Result.fromString('UNSTABLE')
In the Console you'll see:
[PostBuildScript] - Execution post build scripts.
[Current build status] check if current [ABORTED] is worse or equals then [ABORTED] and better or equals then [UNSTABLE]
Run condition [Current build status] enabling perform for step [Execute system Groovy script]
Script returned: UNSTABLE
I've seen a number of examples that execute a pre build system groovy script to the effect of
import hudson.model.*
def thr = Thread.currentThread()
def build = thr?.executable
printf "Setting SVN_UPSTREAM as "+ build.getEnvVars()['SVN_REVISION'] +"\n" ;
build.addAction(new ParametersAction(new StringParameterValue('SVN_UPSTREAM', build.getEnvVars()['SVN_REVISION'])))
Which is intended to make SVN_UPSTREAM available to all downstream jobs.
With this in mind I attempt to use $SVN_UPSTREAM in a manually executed downstream job like
https://code.mikeyp.com/svn/mikeyp/client/trunk#$SVN_UPSTREAM
Which is not resolved causing an error.
Can anyone spot the problem here?
The bleeding edge jenkins build pipeline plugin now supports parameter passing. Eliminated the need for the groovy workaround for me.
Make sure that the parameter you are passing downstream is not set as a parameter in the downstream job where you wish to use it. That is, in the downstream job, if you have "This build is parametrized" checked, do not add SVN_UPSTREAM to the list of parameters. If you do, it overrides the preset value.
I'm using cruisecontrol.net for integration builds along with external source control. The source control (GETMODS) script fails, this is fine and I know why, but the build stays green for some reason when it's expected to fail. CruiseControl shows the exception on the output window below, so why doesn't the build fail?
ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed:
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute
(ProcessInfo processInfo)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.GetModifications(ProcessInfo info, DateTime from, DateTime to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ExternalSourceControl.GetMod ifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl sourceControl, IIntegrationResult lastBuild, IIntegrationResultthisBuild)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.GetModifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.Project.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Integrate()
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Run()
I guess the reasoning would be that the source control block is only used:
to check if there are any changes in the source code which require a rebuild, and
to get all the source code needed for the build.
If this action fails it has nothing to do with the source code and the commits to it. It's an infrastructural problem that prevents the build from happening at all therefore technically the build hasn't fails. It hasn't even started.
With a version control block inside cc.net, it search for repository modification.
If cc.net is unable to contact the repository, it can't start the job.
The result is an exception.
If you want to ignore this, this can help (simple retry counter) !
Can we tell CruiseControl.NET to ignore source control timeout errors?
<maxSourceControlRetries>5</maxSourceControlRetries>
<stopProjectOnReachingMaxSourceControlRetries>true</stopProjectOnReachingMaxSourceControlRetries>
<sourceControlErrorHandling>ReportOnRetryAmount</sourceControlErrorHandling>
I believe this is a recent change to ccnet. We are running two versions on separate machines. Version 1.4 breaks the build if it can't get to our svn repository, but version 1.5 will not break the build. I haven't looked into it yet, but there may be a switch to force 1.5 to break on failure to retrieve code.