I have a couple of jobs both would trigger on Monday but 1 st project on 1st Monday and 2nd project on 2nd Monday. I couldn't use the Jenkins cron to trigger the project based on condition
because cron can be used to trigger a project on a specific time of the day or week of the day alone (eg 0 6 ** 1 to trigger project on Monday morning 6 AM) and not based on condition.
I am looking for a solution where I could use the cron to trigger the project but it would have some condition only if it passes the project would be triggered.
Currently jenkins cron doesn't support triggering project based on condition.
You can do this in two ways
i)The simplest way is to create two projects, one for running in even week and other for odd week.
ii)Once the project is triggered you write a condition either using windows batch command or shell script to check if the current week is as expected (Odd/Even) if it meet the condition you proceed the next step or fail it.
But the issue with this solution is you will have a unnecessary project.
i)A bit hard but stable way is have a Parent Project and two dependent(child) project - i.e one for even and other for odd
ii)In the parent project execute a shell/windows batch command to check if the current week is odd or even refer - Date convert to week number based on it you create a variable and set value as true or false and then write the values into a property file
iii)Then convert the value as a environment variable using Jenkins Environment Injector Plugin (url - https://plugins.jenkins.io/envinject/) for details on how to convert refer - How to set environment variables in Jenkins?, Now you can access the value across the project
iv)Create a new conditional build step (Plugin url - https://plugins.jenkins.io/conditional-buildstep/ )
In that trigger your child project based on comparison of environment variable with a expected condition (i.e if "TRUE" then trigger Odd week project)
You can trigger the build, check the condition, and bail out of the build if the condition does not hold. You can optionally fail the build in this case.
Related
I am using $(Rev:.r) in my build number.
Major.Minor$(Rev:.r)
This works perfect and increments on every build and gets reset if the the major or minor version gets changed.
But the numbering starts at 1 and not 0. So the first build is not 1.0.0 but 1.0.1 which is not really what I am going for.
So is there a way to make the Revision start at 0?
Thanks for the help...
P.S. Unfortunately it is not possible to use Git and GitVersion in this project.
No, this can't be achieved.
What is the Rev?
Use $(Rev:.rr) to ensure that every completed build has a unique name.
When a build is completed, if nothing else in the build number has
changed, the Rev integer value is incremented by one.
Source Link: Build number format
Moreover, anytime you change your Build Number in a TFS build, the revision resets to 1. It' by default, you could not change this value. Since if you could be able to set the value start from 0， it's also should be able to set it start from 100. This will mess up the build number.
This might be old thread but I have found a solution that worked for me.
I have variables for MinorVersion and MajorVersion. Then created my own Revision variable called RevisionVersion and made a counter expression like that:
$[counter(format('{0}.{1}',variables['MajorVersion'],variables['MinorVersion']), 0)]
And now build number can be set as
$(MajorVersion).$(MinorVersion).$(RevisionVersion)
If MajorVersion or MinorVersion changes RevisionVersion is reset to 0. This gives 1.1.0 build number format and with every new build Revision part is increased by 1.
As a workaround to reset the revision number, you could create a clone of the existing build definition and kick off a new build with the recently created definition. This will initiate a new build starting at revision # 1.
Here is how to clone the build definition, click on the 3 dots next to the definition title under Build definitions page. Refer the screenshot below;
Click here to view screenshot - clone a definition
As like 1.0.0.1 if you have set the format to be 1.0.0$(rev:.r) in the build format field.
Otherwise resetting the revision # within a build definition isn't possible. I have tried deleting earlier builds and also tried manually setting the build number to 1.0.0.0 to reset but nothing worked.
Here's how I do it.
I use branch name to set the version number. I create a branch called release/1.2.3 to create a release 1.2.3. I suppose one could use variables.
Hence my trigger will be on the release/* branch
I will then create a counter from the branch name which will be reset every time I change the branch name.
variables:
buildCounter: $[counter(variables['build.sourceBranchName'], 0)]
And, finally, I'll use this in the name after the variables block.
name: $(build.sourceBranchName).$(buildCounter)
I am using the vNext build system of TFS 2015.
I currently have the my builds versioning in the traditional format. Major.Minor-rev.RevisionNumber. So, if I have a build for Major 1, Minor 12, the build version would look like 1.12-rev.1 when I start. I would like to know if it is possible to have the build version start at a number other than one, say 55. Such that the build version would look like 1.12-rev.55, and then increment by one as usual after that.
Actually, it is possible to effect this in a vNext build without hacking the database.
There are 2 steps.
First, you will need to implement a powershell build step (as the first step of the build) with the following inline script:
#Set the BuildNumberOffset. (Change this to the difference between the TFS build number,
#and the number that your build needs.)
$BuildNumberOffset = 543
#Don't change
$BuildNumberParts = $($env:BUILD_BUILDNUMBER) -split '\.'
$TFSRevision = [int]$BuildNumberParts[$BuildNumberParts.Length-1]
$BuildNumberParts[$BuildNumberParts.Length-1] = ($TFSRevision + $BuildNumberOffset).ToString()
$BuildNumber = [string]::Join(".", $BuildNumberParts)
Write-Host "##vso[build.updatebuildnumber]$BuildNumber"
Second, on the Label format field of the repository tab set the label format to "$(Build.BuildNumber)" instead of "$(Build.DefinitionName)$(rev:.r)". This is important so that your label will be the same as your updated build number.
There is a way to do this. It isn't pretty, but it works.
Assuming you have a build number format of something like $(Major).$(Minor)-rev$(rev:.r)
To do this queue up a build which will get the number 1.12-rev.1. Then go to the TFS database and into a table called tbl_Build. Find that last build you did and change the value in the BuildNumberRevision column to 54.
The next build that fires off will now be 1.12-rev.55
Unfortunately, it's impossible.
Every build definition has a build number format field where you can use some macros to dictate what the resulting build number should look like. In this format we are using $(Rev:.rr) Its start by one.
What is $(Rev:.rr)?
To ensure that every completed build has a unique name. When a build
is completed, if nothing else in the build number has changed, the Rev
integer value is incremented by one.
Source:MSDN
Moreover, if you want to generating a custom build number without increment.
Here is a blog with detailed procedures:Generate custom build numbers in TFS Build vNext
Couldn't we just manually set this in the format for one build i.e:
$(Major).$(Minor)-rev$(rev:.54)
and then afterwards revert back to:
$(Major).$(Minor)-rev$(rev:.r)
Not tried it, but if it works it'll save hacking around in the database.
You can do this easily, but only if you are using a Git repository in conjunction with a tool called GitVersion
It is a wonderful tool that I always use with my git repos. For your use-case: When you have version 1.2.3 and you want to jump to version 1.2.55, you just add a git tag 'v1.2.55' and it will start the versioning from there. GitVersion is a lot more complicated and does a lot more, but that is one of the features. You don't have to mess with special PowerShell scripts or anything, it instead reads your git repo history and git tags overrides the calculated versioning. There is already a TFS/VSTS/Azure Devops extension called GitVersion that works great from the same developer.
The Answer of #Steve Sims works still with TFS 2017 vNext. Thanks a lot!
I had only to do the first step "to add the script as an inline powershell script in my build." Thanks to #PainElemental
With this "Build number format" in the Options-Tab it works:
$(BuildDefinitionName)_1.2.0$(rev:.r)
I didn't label my sources with the build, so I don't checked:
Second, on the Label format field of the repository tab set the label
format to "$(Build.BuildNumber)" instead of
"$(Build.DefinitionName)$(rev:.r)". This is important so that your
label will be the same as your updated build number.
I think, you can edit the Label Format on the "Advanced" GetSources Options. (usually hidden).
This was also very painful for us, migrating from a existing CI system with it's own build numbering, we needed build numbers to increment from a specific value. Hacking databases wasn't allowed in the organisation, offsets seemed a cludge.
In the end, we used an AutoIt script to start and stop builds and delete the build result using the WebUI and left it running. Not nice, but it did the job.
Needs tweaking for screen resolutions and such, timings also perhaps. Use AutoIt Window Info to find the button locations, make sure browser is fullscreen (not windowed) Run it for a few cycles to ensure it robust before setting the loop larger.
#include <AutoItConstants.au3>
;Increment TFS build count (Chrome browser buttons locations). Start from build result page.
For $i = 1 To 15 Step 1
ConsoleWrite ( "Loop " & $i & " of 5" & #CRLF )
Sleep(200)
MouseClick($MOUSE_CLICK_PRIMARY, 1800, 200, 2)
Sleep(500)
MouseClick($MOUSE_CLICK_PRIMARY, 1150, 881, 2)
Sleep(2000)
MouseClick($MOUSE_CLICK_PRIMARY, 1800, 200, 2)
Sleep(500)
MouseClick($MOUSE_CLICK_PRIMARY, 1055, 165, 2)
Sleep(10000)
Next
TFS/Devops is a really immature CI system, and it's not a patch on what we were running. Unfortunately corporate policy said we move to TFS, as nobody ever got fired for buying Microsoft products (but plenty of people should have got fired for buying them/forcing them where they don't belong).
I have a parent job which runs multiple times in a day, I have a child job which has to run only once a day only if the latest staus of parent job is successful.
Can you please let me know, different ways of doing it.s
Regards
Jagdish
Use Post build trigger
Trigger your child build if parent build is succeed.
Trigger one more child job from your child job to disable the job.
(you can easily disable or enable jobs by using groovy scipts.)
I would implement a simple counter + flag file.
Counter written to a file every time the parent job runs.
If the counter reaches N, create a flag file.
Use the Conditional BuildStep Plugin and check if flag file exists.
If exists, and parent build is good, reset counter, delete flag file and trigger child job.
I hope this helps.
Thnanks to you all for the ideas.I implimented this using a python script which compares current time with the time I want to run the job, if current time is less then it does not trigger the job and if it is equal to, greater than and less than one minute from runtime+1 min then it executes. So if my my designated runtime is 7PM, I compare current>7PM and current<7:01 PM.
So this way, even if parent job runs every 5 minutes, this child job triggers only once at 7PM. Use Trigger Remotely option to enable trigger remotely and execute this python script from parent job.
I've had a dig around but can't find an elegant solution for what I want to do, so I hope some of you may be able to offer some suggestions. I've also asked this question on a jenkins forum, but no takers.
I want to be able to run a jenkins parent job with parameters that will feed down to triggered jobs, and then group all the job run results in a view dynamically.
The use case I'm trying to cover is: We have 10+ different jenkins jobs that run suites of tests, I want to simply manage a run of all those jobs to run against a specific code branch, on a specific test environment, and see the results (in one view) for only that run. The complication is the same Jenkin job may be run against another release or test environment and I don't want to see those results.
We already have the parent job triggering children with parameters, but I can't figure out how best to group the results.
I know I can create filters for views, but the name of jenkins jobs is static, and I want the view created at runtime, without having to build it myself. We do use the 'Set Build description' Plugin, so I could create a view that filters for a unique build descriptor, or something similar. But there doesn't seem to be a way to create views with filter programmatically.
Other considerations would be clean up. I wouldn't want a years worth of views clogging the views, so I need a way to clear out old runs too.
Any ideas to kick me off?
For groupping of reports you can just use a simple logic instead of finding a Jenkins plugin. You can place all the result files (preferably XMLs) in a common folder/ file server and at the end of execution of all the suites (jobs) you can trigger a common job which will process all the XML files and generate a common report. By this you can have " consolidated + individual reports ".
I have done it using Perf Publisher plugin which process XMLs and gives a beautiful aggregated report.
Job1 ----> Report1 ----> Move report of report folder
Job2 ----> Report2 ----> Move report of report folder
Job3 ----> Report3 ----> Move report of report folder
.
.
.
Job n ----> Report n ----> Move report of report folder
So after completion of job n, trigger Report job which will operate on "report" folder containing all the reports!
Hope it helps!
I have a partial solution:
All jobs accept a parameter called VIEW_IDENTIFIER.
Parent job is kicked off with a unique VIEW_IDENTIFIER being set, and all the child jobs have that passed into them when run.
After all jobs are run I edit a Jenkins View that has a 'Job Filter - > Parameterized Jobs Filter - > Name = VIEW_IDENTIFIER, Value = my unique ID set for the run'
This results in all jobs run with that unique ID being grouped in one single view for review.
The shame is I have to do the manual edit of the Job Filter.
I have 3 Jenkins jobs 'J1', 'J2', 'J3'. Now I have to create another Job 'Jselect' which takes user inputs or a drop down having values J1, J2, J3. Based on the user selection it should trigger the jobs J1 or J2 or J3.
To achieve this, I installed DynamicParameter plugin and created the job 'JSelect'.
In JSelect job, I selected 'This build is parameterized' option and then added a Dynamic Choice Parameter.
Provided the name as : Choose Target Job:
Choices Script as : def list=['J1','J2','J3']
When I Saved and build the job, a dropdown is coming as expected. But Iam not understanding where to capture this input and how to call other jobs based on this input.
I am on the right approach? Can someone please help on how to achieve this?
you need to trigger J1/J2/J3 based on some condition from Jselect.
I suggest you the below approach.
build step make variable or property file to decide the condition.
eg(when error ~>5=low ,error ~>15=medium, error ~>50 =high)
Use https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin
It helps you to select downstream project based on different condition.
Make sure you uncheecked"trigger build when there is no parameter".
Hope its resolves your issue.