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
Related
Environment:
I have around 100 pipelines that run on a number of triggers.
Outcome: I want to create a master pipeline that calls those 100 pipelines.
Currently, I've created a list of pipeline names and put them to an array. Then I was hoping to use forEach and execute pipeline activities to pass those names.
Issue, it seems that execute pipeline activity does not take variables or it is not obvious how to do it.
I do not want to create master pipeline manually as it can change often and I hope there must be better way to do it than manually.
You are correct that the "Invoked pipeline" setting of the Execute Pipeline activity does not support a variable value: the Pipeline name must be known at design time. This makes sense when you consider parameter handling.
One way around this is to create an Azure Function to execute the pipeline. This answer has the .Net code I leverage in my pipeline management work. It's a couple years old, so probably needs an update. If you need them to run sequentially, you'll need to build a larger framework to monitor and manage the executions, which is also discussed in that answer. There is a concurrency limit (~40 per pipeline, I believe), so you couldn't run all 100 simultaneously.
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 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.