Context:
We build our maven apps in which version number is injected by a build.properties file. Problem with this approach is that for every release, version number needs to be bumped manually.
Browsing online to fix this problem, i bumped into version number plugin which offers some cool ways to fix the issue.
For instance -Dproject.version=${BUILD_YEAR}.${BUILDS_THIS_YEAR} will solve the issue for me
Problem
I have issue setting up the values for the defined variables
Quoting from the doc:
Initialization Values
Before the build is started, the number of
builds this year / month / week / day can be specified on the command
line or via the job's plugin-configuration web-GUI. If they are
specified, then they will override whatever values are currently in
production. This allows you to migrate your version number from
another system to Jenkins if you choose to do so.
Additionally, it is possible to automatically override the number of
builds this year / month / week / day with values taken from
environment-variables. Instead of just providing a simple number in
the form-fields of the job's plugin-configuration which overrides the
value for the next build (as described above), you can instead provide
an environment-variable whose value will be extracted and used during
the next builds. If it is not set or its value is not convertible to a
positive integer (without loosing precision), the value of the
previous build will be taken instead and increased by one (as is the
standard behavior).
In the last sentence, it says
If it is not set or its value is not convertible to a positive integer (without
loosing precision), the value of the previous build will be taken instead
and increased by one (as is the standard behavior)
So, going by this i built an jar with injected values of BUILD_YEAR and BUILDS_THIS_YEAR, worked as expected (jenkin says Building my_app_2019.1-SNAPSHOT). After that, i removed the variables assuming that they would be picked but unfortunatley jenkin says Building my_app_${BUILD_YEAR}.${BUILDS_THIS_YEAR}-SNAPSHOT.
There is no relevant doc around this or may be i have missed something totally obvious
Question
How do i ensure these var are injected correctly in my maven builds? or rather how do i populate the values using the plugin?
This is not a jenkins pipeline, its a simple jar builds.
Missed setting up Create a formatted version number as below :
updated as per image above and changed command to -Dproject.version=${VERSION_NUMBER}-SNAPSHOT.... voila!!!!!
Related
I have a build configuration that runs on multiple branches. I would like to set a failure condition that compares code coverage numbers, but only within the current branch.
What i've done:
Added a build step that sets a custom parameter "CurrentBranch" to the value of the current branch (either %teamcity.build.branch% or %teamcity.pullRequest.target.branch% if its a PR build)
Added a build step that successfully adds a tag to the build (using the REST API) with the value of %CurrentBranch%.
Added a failure condition that compares the current code coverage with the last successful build with tag %CurrentBranch%
However, when I execute the build, I get a warning:
Invalid settings for build failure on metric
buildTag: Tag must be specified
If i explicitly set the tag in the "failure condition" properties to one of the branches, it works as expected.
Anyone know what I'm doing wrong?
I've also tried using the original %teamcity.build.branch% parameter. That did not produce the warning. So it seems to support parameters, but not parameters set during the build?
Edit: If I initialize my custom %CurrentBranch% parameter with %teamcity.build.branch% I no longer get the warning. Will need to check if (in the case of pull-requests) it actually uses the correct branch for metrics comparison.
The behavior still seems odd. If anyone can shine a little light on this, I'd be very thankful!
I want to use the maven-release-plugin to release my application. However,
I found that the user input is not very securised. I want to know if it's possible to do as parameter :
type patch to increment last number version (1.0.X+1)
type minor to increment middle number version (1.X+1.O)
type major to increment first number version(X+1.0.0)
Avoid putting 0.0.4 when the 0.0.5 is already released
You can let Jenkins construct the command line parameter -DreleaseVersion for you. The build-helper plugin with the goal build-helper:parse-version allows you to get a lot of useful Maven properties, including the actual and next number for major, minor and incremental.
I have some code which has worked in multiple installations for about a year. Today im doing a small change to a control and then another control seems to have developed an issue. When at runtime im getting a 91 error object variable or with block variable not set.
I therefore looked at the problem line which is: -
If Screen.ActiveForm.name = "frmFoutmelding" Then Exit Sub
so I noticed the name was lowercase. if i delete .name and rehit the "dot" then it shows me i can use .Name but as soon as i move from this line it drops back to .name
I've checked for instances of name and it appears everywhere in the code in different modules but i cant find if i have accidentally defined this lowercase name anywhere?
Googling doesn't seem to show much but i feel Im googling the wrong terms
chaps - thanks for your suggestions - this was the first instance of the lowercase name and searching as Jim suggested didn't reveal anything I'm afraid. What I did discover was that this was suddenly being run before any forms had actually been displayed and so the count was 0. I therefore, did an on error to check the form count and exit the sub if it =0 then if not to carry on with the line I thought I was having issues with.
It's likely that you did create a new variable or property called (lower case) name, or that some included reference did the same. It's possible to use reserved words as variable names in some cases, but it requires taking specific steps.
I would first search your code for instances of name As to see if you created a variable (this assumes you use Option Explicit, which is a must IMO). Then search for Property*name with * as a wildcard.
If those fail you could try unchecking references or components to see if any of them define name. If none of that finds anything, please post back here.
Jim Mack covers a lot of the potential issues. I think another is if you typed a lower case '.name' in association with Activeform at some point earlier in the same code module - the VB6 IDE checks in the current module and uses that to define what case to use. Look further up the same code module (sub or function).
Ultimately, check what changes you made by comparing the old source to the new in a file comparison tool like windiff - you do have backups, right?
I have a parameter for which I'm showing a prompt. I've set a default value for it and that works fine.
What doesn't work, however, is that if I choose to enter a different value when running the build, then on the next build this value automatically becomes the new default value, so to say.
I'd like the default value to always be fixed and if you enter a different value in the field, then that value will be used just for this build (and the next build will fallback to the fixed, default value for this parameter).
Is this possible and how can it be done?
Currently it's not possible. The related request is https://youtrack.jetbrains.com/issue/TW-21453, please vote. As of now you can use "Reset" link.
As far as I know, there's no built-in solution for this.
To solve your problem, you could use a Command Line (or Powershell) Build Runner that runs as the last step of the build. There you can reset your parameter by setting it to the desired default value using this as script content:
##teamcity[setParameter name='your.parameter' value='desiredDefaultValue']
I would recommend using a separate parameter to save desiredDefaultValue instead of a hard-coded value.
this is kind of a follow up to this question: ClearCase UCM: Get latest version from Dev-stream
I need a dynamic view to have the LATEST (or CHECKED_OUT) version of certain components of a UCM VOB and at the same time specific baselines for other components.
For components where I want to include a specific baseline I can just include them with
element component_1/... BASELINEwhere BASELINE is just a name of a baseline (without the need to specify a stream or anything).
The folder of the component is later included by a element * /main/LATEST-directive (at least to my knowledge).
As mentioned in the above mentioned link I can also add a line likeelement component_2/... /main/INT-STREAM/DEV-STREAM/LATEST which should give me the latest version of DEV-STREAM.
Now I found out that sometimes (when the DEV-STREAM was 'branched' from version /main/0 I need a element component_2/... /main/DEV-STREAM/LATESTto get the latest version of this component. And in other cases there is no DEV-STREAM (because the file was obviously never changed and therefore the DEV-STREAM is not created), so I need a third lineelement component_2/... /main/INT-STREAM/LATEST.
And the same applies to version CHECKED_OUT.
As I want to create the config spec by script I would either need to find out where the component_2 is located (in the INT-STREAM or the DEV-STREAM) and where the DEV-STREAM was branched off or I would have to include 6 lines (one of them should match) for each component - in comparison to the one line for the baseline. Obviously I wouldn't want to include each file (there are VERY many) but would like to be able to simply specify the component with all its subfolders, just like for the baseline.
Thanks for reading - and obviously for any answers
You can avoid all those multiple rules with:
element component_2/... .../DEV-STREAM/LATEST
element component_2/... .../INT-STREAM/LATEST -mkbranch DEV-STREAM
The order is important, and the '...' allows you to select a branch without knowing of its exact parent branch.