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!
Related
Say, I have a tag based pipeline on bitbucket like this
pipelines:
tags:
v*:
- step:
I don't want to run pipelines on PATCH version changes semver.
For example when going from tag v1.0.0 to v1.0.1 I don't want to run pipelines. Pipelines should only run when there is a MINOR or MAJOR change like. v1.0.0 to v1.1.0 or v2.0.0.
How do I do this?
Is there a [skip ci] equivalent when pushing tags to indicate I don't want pipeline to run for this tag?
Unfortunately, I cannot think of an easy way to achieve such behaviour, but can present an idea of a workaround.
First and foremost, we cannot specify patterns to skip the pipeline, only patterns to trigger it. After we entered the step, we can check a condition we're interested in, and perform early graceful exit if this condition is met, like this:
script:
- <check if tag is a PATCH update> && echo "Will not run the step for a PATCH update; gracefully exiting" && exit 0
Be advised that your step will still technically be triggered, so its startup time will be affecting your quotas.
Second, is what this <check if tag is a patch update> actually looks like.
Bitbucket exposes the name of the tag that triggered the build in the environment variable called BITBUCKET_TAG (see this doc for details).
However, this name itself is not enough to decide if you want to run the step or not. You will need to:
Retrieve the value of the previous tag using Bitbucket REST API. This endpoint looks like something you can make use of.
Compare it to $BITBUCKET_TAG in the CLI using bash, or something friendlier, like Python, if it's included into your build environment.
By 'compare' I mean checking if the tag update was PATCH or not. Let me omit the implementation details :)
This is cumbersome, up to unfeasible depending on the lifecycle of your repository, but you could write an alternative pipeline that does nothing for minor patches on your current minor tag and bump the definition in the very yaml key along any other you may perform.
definitions:
yaml-anchors:
- &your-step
script:
- do your thing
- &noop-step
script:
- exit 0
pipelines:
tags:
v1.n.*: # bump me!
- step: *noop-step
v*:
- step: *your-step
The same question has been answered here:
https://community.atlassian.com/t5/Bitbucket-questions/bitbucket-skip-pipeline-based-on-tag/qaq-p/2008586
The gist is that [skuip ci] in the commit message causes no pipeline to run.
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!!!!!
I want to have part of my destination path in build.cake be based on the branch being built. The top of my build.cake script says:
var branch = Argument("branch", "Master");
and I modified my Team City Build step to include
.\build.ps1 ... -Branch %teamcity.build.branch%
but Team City complains that I have no eligible agents
Implicit requirements: teamcity.build.branch defined in Build step:
Build
I'm new to TC and Cake so I'm likely missing something obvious. How do I hook this up?
You are correct that %teamcity.build.branch% will give access to your branch name. However, this variable is blank unless you have a branch specification in your VCS root settings. In order to use say master as your build.branch parameter you need to add: +:refs/heads/(master) to your branch specification. Whatever is in between the parens will be put in the build.branch variable. If you might be building from multiple branches, you might have something like the following:
+:refs/heads/Release/(765/1.0)
+:refs/heads/Release/*
This would give your build.branch the name of branch as it appears in git after the Release/.
Also see Johan's answer: https://stackoverflow.com/a/27829516/6222375
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.
I am using maven with a Fortify360 plug-in to analyze the source code. The sca:translate step runs fine and seems to generate the correct sca-translate-java.txt files, but the sca:scan step does not actually run the scan on any of the sub-projects.
I am given no reason why, just error message like :
* Skipping scan of sub-project
I am new to Fortify. Anyone have experience with this, and have some ideas for why it could be skipping the scans?
Thanks!
If your projects are inheriting from a top level pom, you need to also use the -Dsca.toplevel=foo parameter, and also you need to set the build ID manually.
So in the translate step, add the extra -D parameter to set a build id.
In the scan step, add the same -D parameter to set a build id.
Also in the scan step, add the "top level" -D parameter.
As it is nicely self-documented in sources here ScanMojo if you want aggregated result for entire project you need to specify both <buildId>...</buildId>and <toplevelArtifactId>...</toplevelArtifactId> and they should match otherwise it skips sub-projects.