We have a Jenkins job that is parameterized that we run every night for our testing. We'd like to be able to check the results of this build in Jenkins in the morning via either the Downstream Build View, or the Build Pipeline View, as we want to see which sub-components passed and failed.
The problem is, we also sometimes run this build manually in the morning using the rebuild button so that we get the same parameters. When this happens, the previous nightly build seems to get overridden with the results of the new build. If someone runs a sub-job with the rebuild button, that sub-job and it's children's results from the previous nightly build now show as the newest run.
I've been looking into the rebuild plugin and how it works, but I can't find this answer. Does re-building always build on top of a previous build, or is there some way to re-build with the same parameters, but to give the new build a unique build number so as to preserve the results of the previous run?
Basically what I'm looking for is "New build with same parameters as the old build" instead of "Re-run the old build". Any help you could give would be greatly appreciated.
The Rebuild Plugin always starts a new build (but keeps the old parameteters , although you're able to edit them before the build starts). This means that a new $BUILD_NUMBER is set.
Actually it sets a new build number for the next build . You should be , however, be able to edit or keep the same parameters imo.
Related
I have a custom TFS Build template that includes a procedure that runs a process that involves getting some data from a server and checking it into TFS before moving onto the main build process.
The steps are as follows:
Set build number
Run our custom script - get data, check into TFS
Initialize environment
Get sources from Team Foundation Version Control
Associate the changesets that occurred since the last good build
Compile, Test and Publish
The issue I appear to be having is that all change sets since the last successful build are included, except, the change set associated with the script run at step 2.
Does anyone know what could be going on here? my guess is that the logic that is looking for the change sets since last build is using a cut off that is set at the moment the build is requested (hence why the last change set is ignored) but this is just an uneducated guess.
Thanks in advance for your help.
Trying the steps below:
Edit your build definition and go to "Process" tab.
Enter "T" under "Get version" option.
Queue the build and check the result.
I would have two builds chained: the first build generates and check-in the files the second simply pulls them down.
I have a job to maven build our project, we now have one job per release version. As the number of releases grows, there are too many jobs and very hard to find the one we need.
I wonder if there is a way to launch the same job with different parameters? The problem is one job only has one workspace, so I'm not sure if it's possible?
Thanks.
Use This build is Parameterized option to build the jobs. Using this you can build the same job for different parameters. You will be asked to enter the parameter before building or you can also give a default parameter and you can have multiple parameters.
It is good the archive the artifacts which you need later.
You can also have the option keep build forever, this will keep the builds permanently Ir-respective of the number of builds to keep.
To use above option you should enable Discard old build option.
You can also link your repository directly to Jenkins which will trigger the job whenever a new commit is made to master or a new tag is created.
I've a Jenkins job I want to keep running all the time. When a build is ending, I want to immediately trigger another build. How can I do that?
Thanks, Omer
There are two different job configurations for that:
Build Triggers -> Build after other projects are built
Add a post-build action Build other projects
In both cases, you can enter your own Project, so it'll be triggered again every time a build is completed. You can also specify if this should be done only while the project is stable.
There is however one (probably more) drawback in this approach, which is that it'll create enormous overview pages, where all build triggers are listed:
So i'd recommend to do something else and for example use the Jenkins API to trigger a new build. There are many ways to do that, one simple example is adding a build step Execute shell and do something like:
curl -X POST http://localhost:8080/job/$JOB_NAME/build
If you have configured the Jenkins URL, you could also use $JOB_URL. You can also add post parameters to trigger a parameterized build.
I want to have Jenkins CI test every branch but not all existing one, solely the ones which received a recent push.
I have set up a GitHub web hook which triggers new builds. This works fine for the branch specifier set to master. Now I tried ** so every branch is built.
The problem: on the first push it tries to build every branch, which is simply too much and would take ages. Is there a way to limit this?
There is no configuration which supports the feature you are requested and since it looks like there is no plugin yet. Your best shot would be to implement your own plugin that can specify a certain date threshold for branches.
Having said that, to solve your problem I would simply:
Empty the shell script for your job
Trigger a new build
Set your shell script again
This way all remote branches get checked out, run and marked as successful within no time due to the empty shell script. After re-enabling your actual shell script you are good to go.
We have a nightly TeamCity build which releases the latest code to our test website, restores the database to match production, then applies any schema and data changes we have in TFS.
If this nightly build fails, the website is down until we manually fix the code and/or the database scripts and restart the build.
What I'd like is to automatically rollback to the last successful build so the website is available despite of any build break.
After spending a bit of time investigating, here's my proposed solution:
Nightly build runs, creating a new label in TFS (something like Nightly-build-{build number})
Create a new TeamCity build which triggers after the nightly build runs
Find the last successful nightly build number
Get the version relating to that build number's label in TFS
Rollback builds (it doesn't matter if the nightly build just finished successfully)
What I don't know is how to have the rollback build get the version based off a label.
Any help for this, or another solution, would be appreciated.
Cheers.
A judicious use of the TeamCity REST API might work here. I'm cribbing a bit from this question, which covers some of this same territory. You might could do something like this (and I'm just spitballing here):
Create your VerifyBuild configuration as per your Step 2.
Create a RollbackBuild configuration that can deploy from a given label, the build number of which is parameterized as %rollback.buildnumber%
In VerifyBuild:
Use the Rest API to list the most recent nightly production deployments
If the most recent deployment was a SUCCESS, then you're done.
If the most recent deployment was a FAILURE, then get the build number of the last successful build.
Use the Rest API to set the %rollback.buildnumber% of the RollbackBuild to the last successful build number.
Use the Rest API to queue a RollbackBuild.
I'm proposing this method because I don't know how you would dynamically fetch the correct label for RollbackBuild prior to the checkout, so I'm using VerifyBuild to pre-populate it.