I have separated a big Hudson job into smaller jobs. Job A does the main build and Job B does another build with a different configuration. I have configured Hudson, so that the A triggers B and that works fine, the problem is that Job A has the original build number and B has started from 1.
My question is: Is it possible to pass the BUILD_NUMBER environment variable somehow from Job A to Job B? The build number is used in the build artifact names, hence it would be nice to have the numbers match between artifacts.
Thanks.
Use the parametrized Parameterized Trigger Plugin, which will allow you to pass the build number from A to B. You will not be able to actually set the build number in job B, but you will have the build number from A to generate your version number.
If you want to synchronize the build number, you can edit the file nextBuildNumber in the job directory to match the number from job A. Be aware that these numbers will drift apart over the time since when A fails B will not be started.
EDIT I just stumbled across the Next Build Number Plugin. Have a look, If this one helps you.
Related
I am new to teamcity. I have created a build which should be run with different parameters. Is there a way to schedule builds to run with different parameters ?
That means, I should set x value for a parameter for a build scheduled at 9 AM and y value for a parameter for a build scheduled at 10 AM. I looked into schedule trigger,but I couldn't find a way to give custom parameters for each triggers
Convert your build configuration into template. Then, create another build based on this template. Add different parameters into those build configuration and run them on different hours with build scheduler.
If you wish to be more conservative with the number of build configurations used then create two different shell scripts that if ran by the correct trigger would produce your desired results (ex: setting env variables). Then in the Schedule Triggers add a trigger rule that excludes the shell file you do not want. In the build step if one script exists run it else run the other. But you should prefer the answer given by #Peska in most cases.
very basic example:
touch test{1,2}.sh #will create two files named ./test1.sh and ./test2.sh
#Trigger rule excludes one
./test?.sh #will run all files matching that pattern
I've got Jenkins job A that triggers job B and afterwards executes a shell script.
Inside this shell script of Jenkins job A I want to use a variable set by Jenkins Job B.
How can I do this?
This can be accomplished in many ways. One way would be to configure Job A to have a build step, that triggers Job B, and fetches variables in a document after Job B has finished. Then Job A can read those variables and use them in later steps.
There are several things to consider here though. First of all this requires Job B to finish before Job A can/should continue, so if you are thinking of parallel job execution this isn't ideal. Secondly, when dealing with env variables you will need a plugin to make variables available outside of the build step (exporting isn't enough), check out the EnvInject plugin. And thirdly, if job configuration is becoming complex, there probably is a better way of doing it. With Jenkinsfile and previously pipelining plugins, Job orchestration has improved a lot, and passing parameters around and such is much easier in this new, shiny world. That being said, here is an example of something that works like what you are asking about.
Job A
As a build step, trigger Job B, and let Job A halt while Job B finishes
As the next build step, copy an artifact from another build (Job B latest stable), using the Copy Artifact Plugin.
Do something with the file, for example just printing it's content, it's now accessible in Job A.
Job B
Export a variable and save it to a file
Archive the written file and make it accessible to Job A.
This isn't pretty, but it works at least.
P.s. I'd recommend checking out the Jenkinsfile (https://jenkins.io/doc/book/pipeline/jenkinsfile/) options, it simplifies a lot after the initial learning curve.
In the set of my TeamCity configurations, I decided to make something like an aging test*. And run a single configuration for a 100 times.
Can I make in a few simple clicks?
*aging test - test that is showing, that due time/aging, results will not be changed.
As of now, this is not possible from UI. If you run one build configuration few times without any changes, they will be merged and only 1 will be executed. If you want to run 100, you have to trigger them one by one, after the previous one finished executing.
But the better solution is to trigger builds from script using REST API (for more details see the documentation here), if builds have different values in custom parameters they all will be put in the queue.
HOW: Define a dummy custom parameter, and trigger the build from script within a loop. Pass the value of iterating variable as parameter value. So, TeamCity will think those are different builds and execute all of them.
I am aware of the BUILD_NUMBER environment variable; however, unless I'm mistaken, this is a global variable which appears to be shared among all projects. This is a problem since, if I have two agents running jobs, one script may try to use the current project's build number after another script has updated it for a different project.
Here is an example scenario:
Job J1 starts, executing some script S. BUILD_NUMBER is currently, let's say, 500.
Someone manually starts job J2, which now sets BUILD_NUMBER to something completely different, say, 750.
Script S, which is still running, now reaches the point where it actually uses BUILD_NUMBER, now set to 750 (an impossible value for job J1, which is only up to 500).
Am I correct in this understanding? If so, how do I address this problem?
BUILD_NUMBER is not global to the system. It's local to each job. In your example, J1 and J2 will have different BUILD_NUMBER (J1=500, J2-750) values and they will remain constant - within the job - for the duration of the job.
You can get the latest (completed or currently executing) build number with:
http://[JENKINS_URL]/job/[JOB_NAME]/lastBuild/buildNumber
or from within the job itself, you can use environment variable:
${BUILD_NUMBER}
You can use all other permalinks too, like:
/lastStableBuild/
/lastSuccessfulBuild/
/lastFailedBuild/
and so on.
Unless you are customizing your build number with a plugin such as Next Build Number, your next build number will always be an increment to the latest build number.
The build numbers are per job. They are not global environment variables.
Every time any job is executed, it copies/inherits existing environment variables into a new session. Jenkins/Hudson then adds all job parameters and extra variables (including ${BUILD_NUMBER}) to that new session. They are available as environment variables only for the duration of that session (i.e. for the duration of the job run). Once the job completes, this session is destroyed (along with all the extra variables that were generated for the session).
You cannot access the environment variables of one job-run/session from another job-run/session. You can however access the /lastBuild/buildNumber of another job through the URL method I provided. You can also access /lastBuild/buildTimestamp the same way.
To access job parameters of another job, you can use:
http://[JENKINS_URL]/job/[JOB_NAME]/lastBuild/api/json
or
http://[JENKINS_URL]/job/[JOB_NAME]/lastBuild/api/xml
but you would need to parse the output for what you need.
Use the Get Next Build Number plugin.
https://wiki.jenkins-ci.org/display/JENKINS/Next+Build+Number+Plugin
I'm using several matrix-jobs which usually contain the following steps:
Build, Install, Test
The Build-Step is set as a Touchdown-Step. The other steps are using the binaries created by Build.
I recently added another node to my system which should build these matrix-jobs too. Now my problem is, that Jenkins is distributing the steps of my job to these nodes.
Example:
1. Slave A runs the `Build` step and succeeds
2. Slave B runs the `Install` step and fails due to its dependency on the `Build`-results.
3. Slave A runs the `Test` step and succeeds, cause the dependencies are existing.
The execution of the matrix-job fails, cause its steps are distributed.
My question now is if there is any way to bind the execution of a matrix-job to just one node. It's no problem if different executions are done on different nodes, but the steps of a certain execution should be done on a certain node.
It is no solution to bind the matrix-job to just one node. It still should be bound to a group of nodes.
Since you have these steps as individual jobs, in your "label" axis:
make sure you choose individual nodes, not labels, for each of your steps.
This will make sure that each of your steps runs on each individual slave, and therefore each step will have it's predecessor's workspace.
See:
http://imagebin.org/163627
==========================================================================
Based on comments:
At this point, you have two options:
You can use : https://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin. You can add everything required as an artifact of your "build" step, and have your "install" step copy them over using the plugin. Do the same for "install" => "test".
Combine your steps into a single job, since there is no guarantee that the same node will be "least used" for each step if they are different jobs. The only way to force all jobs to use the same node is by selecting individual node and not label.
Hope that helps...