My team and I are currently building a project with Travis CI, which initiates a script on remote server. When we click to cancel builds in the Travis UI, the Travis build stops but the script on the remote server continues to run.
Is it possible to automatically run a command after cancelling builds, so that we can tell the remote server to stop executing the script?
Thank you to Travis CI support for this email response:
When a build or job is manually cancelled (or terminated by one of our
workers for a different reason) it is killed without any chance of
cleanup. So no, there is no special after_cancelled hook and
after_failure as well as after_script are not executed when
manually cancelling. This has to do with the way our build lifecycle
is implemented and making an after_cancel possible requires quite
some changes.
We are aware of this issue. It has been raised in our public tracker
https://github.com/travis-ci/travis-ci/issues/4221 and is also being
discussed internally. Unfortunately I cannot give you any time frame
when we will address this issue but we will update the public ticket
once there is progress.
Related
I just updated my Jenkins server to 2.32.2 and I noticed in the Release Notes that they added a feature which asks the user for confirmation before aborting a build (this issue: https://issues.jenkins-ci.org/browse/JENKINS-30565)
Is there a way to disable this feature? There are some cases where I have automated job cancellation using scripts and this new behavior would have an effect on all of those scripts.
This change only affects the browser interface. Any cancellation of builds via the Jenkins CLI or SSH interfaces, for example, would not be affected.
We have a job in a jenkins environment which is triggered based on the changes found in the git source code repository.
When the job is running, the git polling log shows nothing and until the job finishes the execution, polling log doesn't have anything on it.
It always shows log after completing the job and another note is that, enable concurrent builds option is not set to make sure only one build runs at a time.
I would like to understand whether it is a known behavior on jenkins front to halt polling when the job is running and whether the concurrent builds option is enabled or not?
I had a similar problem and discovered this: https://issues.jenkins-ci.org/browse/JENKINS-7423
It looks like it's related to the polls requiring a workspace in order to perform the checkout. You can manually kick off new builds and they will pick up SCM changes.
I am trying to implement continuous integration using Jenkins and i came across below scenario.
I have a build, say Build A which is configured to run every 1 hour. This job require another process ( independant background java process ). But what happens is sometimes this background job will not respond or we have to restart the job in order to complete the Build A without any exceptions. If the process is down, we will get console exceptions and build will fail.
I have found a solution for this.
Abort the current Build A and start Build B.
Trigger Build A after build B is success.
But
What i am looking for is, if there is a console exception, pause this build and trigger Build B which will restart the process and I should be able to resume Build A when the build B is success.
There is no easy way known to do that in Jenkins. It would be much easier to start (and possibly restart) the fixture process from the build itself. Perhaps even integrate it into your build/test tool so the CI job can be easily replicated or reproduced locally.
Is there any way in jenkins where as soon as we detect the failed build, job revert back the perforce code to the last successful build changelist and fire a build again.
Flow -
1. so as soon as we have failed build - Notifcation will be sent out to dev team with possible checkins which causing the build failure
Revert back the recent code to the last working code and submit it
Initiate a build.
It is possible, but I don't see any reasons or use case to do it as it is not a correct workflow and can be confusing.
But if you decided to do it, the next steps are required:
Example how to do it using Perforce source control.
Steps inside job settings:
Before build triggers you need to save latest changelist number $P4_CHANGELIST - 1
Perforce plugin for Jenkins: Perforce plugin for Jenkins
Build
Get last error code
Get last error code from the: batch
If code != 0 then checkout and build changelsit $P4_CHANGELIST - 1
Jenkins is not a production server. It runs tasks and do not have options that I know for that purpose.
What is your source code ? webapps ? others ?
What steps are you performing ?
Are you performing some automatic tests ?
My assumption is that you got some tests that may invalidate the build.
These tests should be runned :
* on a mock server to prevent deploying on your server
* or somewhere else
Like that, if build failed, nothing is deployed.
If build success, you can deploy your project normally.
If this not reply to your answer, please provide requested information to undestrand a bit more your job process.
If your using an artifact repository like Nexus or Artifactory to manage your project artifacts then you could always redeploy the previous working version of your application when a failure is detected.
Your not cancelling any checked in code that potentially broke the build but you are preserving your test environment. You can configure Jenkins to notify the user who checked in the latest erroneous change set and they can work on resolving the issue.
Jenkins also provides a rich API which allows you to delete a job, start a job, get information about previously run jobs. You could leverage some of these services along with your artifact repo to achieve the experience you described.
I'm working on a team that is building a RESTful HTTP service. We're having trouble with setting up a Jenkins CI job which will build the service, run it in the background, execute some tests, and then terminate the servers.
Specifics
The server is built in Node.js using the hapi framework and has some unit tests written in mocha.
The tests are written in Java using Maven. (Why not node.js-based tests? Because our testing dept. has invested time in creating a Java-based REST-testing framework.)
The build should fail if the node-based unit tests fail or if the java tests fail.
Our Jenkins box is run by a support team elsewhere in the company; our builds execute on a Linux slave.
Current Attempt
We've got something that kind-of works right now, but it's unreliable. We use 3 build steps:
The first build step is an Execute Shell step with the following commands:
npm install
npm test
node server.js ./test-config.json &
Second we do a Invoke Maven 3 step that points to the test pom.xml.
And third we run Invoke Standalone Sonar Analysis to do static code analysis.
This mostly works, but we depend on Jenkins' ProcessTreeKiller to stop the services once the job completes. We always get the warnings stating: Process leaked file descriptors. See
http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+buildfor
more information
Unfortunately, we've had cases where the service is terminated too soon (before the tests complete) or where the service doesn't get terminated at all (causing subsequent builds to fail because the port is already in use).
So we need something more reliable.
Failed Attempt
We tried setting up a single shell script which handled starting the service, running maven, killing the service, then outputting an exit code. But this didn't work out because the mvn command wasn't available on the command-line. Our Jenkins has multiple maven versions available (and jdks too) and I don't know where they live on the slaves or how to get at them without using the Invoke Maven 3 build step.
Ideas
We've toyed around with some ideas to solve this problem, but are hoping to get some guidance from others that may have solved similar problems with Jenkins.
Have the service self-terminate after some period of time. Problem is figuring out how long to let them run.
Add a build step to kill the services after we're done. Problem is that if the maven execution fails, subsequent steps won't run. (And if we tell maven to ignore test failures, then the build doesn't show as broken if they fail.)
Try killing any existing service process as the first and last steps of the build. Problem is that other teams also use these Jenkins slaves so we need to make sure that the service is terminated when we're done with our build.
Start and stop the node.js services via Maven doing something like this blog suggests. Problem is that we don't know if Jenkins will identify the spawned background task as a "leaked file descriptor" and kill it before we're done testing.
It would be nice if Jenkins had a "Post-build action" that let you run a clean-up script. Or if it had a "Execute background process" build step which would kill the background items at the end of the build. But I can't find anything like that.
Has anyone managed to get Jenkins to do anything remotely like this?
Some brainstorming:
You can turn off Jenkins ProcessTreeKiller, either globally or per invocation. I am not sure why that is not an option for you.
In response to #2, several options:
Post-build actions get executed regardless if build steps had failed or not. This would be a great way to trigger a "service cleanup" task that will run regardless of the build state.
You can setup any build step as post-build action, using Any Build Step plugin, or you can use Post Build Tasks plugin, the latter even gives options to define triggering criteria.
You can change the build state, based on RegEx criteria using Text-finder plugin
You can setup Conditional Build Steps. The "condition" could even be a result of some script execution