Share parameter with dynamic build configure ID in teamcity - bash

I have a build chain with two jobs: B depends on A. B needs to get a build counter from A.
dep.btID.property name could share parameters from A to B.
However, the btID is dynamic create by git for each branch
I have add following to build steps of B(bash):
ABuildID=dep.dev_branch_A.env.BUILD_NUMBER
echo '%$ABuildID%'
or
echo '%${ABuildID}%'
It will lead to no compatible agent
Following could work however, I need to adapt to all branchs
echo '%dep.dev_branch_A.env.BUILD_NUMBER%'
Is there any way in TeamCity 9 to pass a build configuration parameter with dynamic btID from a project A to its dependency (in the same build chain)?
---------------------Update after finding the solution, hope it will help someone in the future------------------------
I have found a solution by request last successful build of projectA via rest api.
In bash:
curl -s https://teamcity_host_name/guestAuth/app/rest/buildTypes/dev_branch_A/builds?status=SUCCESS&state=finished&count=1
The response will provide the many parameter of project_A, build number is included
Please find introduction of teamcity rest API:
https://www.jetbrains.com/help/teamcity/rest-api.html#RESTAPI-URLStructure
Thanks Niraj Gajjar for the answser

You have add projectA in ProjectB as either Snapshot Dependency or Artifact Depedency ( for that go to Dependencies from left panel menu)
After that you can use build counter of ProjectA like
%dep.ProjectA.build.counter%
or
echo %dep.ProjectA.build.counter%

Related

Accessing artifacts from previous run of the same build

I want to implement rerun solution for flaky tests.
I have problem with passing artifacts from previous run on build to next build.
Artifacts B -> B (Run 2)
Is there any option to get artifacts from latest run of the same build in same snapshot? For now I know that only option would be to get artifacts from Teamcity API.
As was said before only option was to get latest build number from TC API and then get artifacts from API by this build number. There is no better option.
Get latest build:
https://teamcity.com/httpAuth/app/rest/builds?locator=snapshotDependency:(from:(id:$parentBuildId),includeInitial:false),defaultFilter:false,buildType:$buildTypeId,state:finished,failedToStart:false,canceled:false,count:1
Get artifacts:
"https://teamcity.com/httpAuth/app/rest/builds/id:$latestBuildId/artifacts/content/$failed_tests_filename"
I'm answering in case if someone else will look for solution.

Pass/share parameter values between dependant builds in TeamCity

Setup: Build CD has has Artifact Dependency and Snapshot Dependency on Build CI. Build CI pulls from VCS root and generates artifacts for Build CD.
Problem: In Build CD I need %teamcity.build.branch% parameter, but it's not available, because it only uses artifacts and has no VCS Roots linked.
Question: Is there a way to pass parameters between dependant builds? (search results in the googles seem of topic)
Workaround 1: I can access %teamcity.build.branch% in Build CD if I link it to same VCS root Build CI is using, but I'd like to avoid having this link and Build CD unnecessarily pulling from VCS (build log shows it does this).
Workaround 2: I could write parameter to a file in Build CI and read from it in Build CD later. This is a hack and I would like to avoid it as well.
Absolutely. In CD, add a parameter called whatever, with value equal to %dep.Build_CI.teamcity.build.branch%. TeamCity will help you figure out the exact value thanks to its auto-suggestion/auto-completion, once you type %dep..

Build a TeamCity config without rebuilding dependent config

In TeamCity* I have Build Config A and Build Config B**.
Config B depends on Config A, so when I ask B to build it checks if A needs building first.
That's usually what I want - but I often want to tell it "just execute Config B's steps without checking if A needs rebuilding".
I can't seem to work out how to do that!
The dependency is both a Snapshot Dependency and Artifact Dependency - so it must be tied to a particular instance of Config A's build - I'm ok to have to specify this.
--
[*] TeamCity v8, but as I started setting this up v9 came out, so will move to that shortly - in case that makes a difference
[**] The names have been changed - and workflow simplified - to protect the innocent
'Do not run new build if there is a suitable one' will only work if there are no pending changes and it's been recently built.
Are you avert to changing the dependency to not be a snapshot dependency and linking it to a particular artifact? You can do that under artifact dependencies by selecting from the drop down "Build with specified build number" or "Latest successful build". Of course you'd have to change it back when you were done if you wanted to switch back to snapshot dependency only.

Get Artifactory artifact by Jenkins build number

I'm investigating a Maven/Jenkins/Artifactory set up as a possible solution for a CI/Release process.
I have a job in Jenkins - call it MYJOB - that builds and deploys an artifact to Artifactory. Now, I want another job that I can run manually that will copy the artifact of a particular build of MYJOB from Artifactory and put it somewhere (not too bothered where right now, but eventually it'll be another server).
For example, let's say build #123 went green, and now my QA team want to deploy the built artifact to their environment for further testing (the idea being to keep this artifact intact and unchanged throughout the testing process, before marking it as releasable). I want them to be able to enter '123' into Jenkins as a job parameter and then kick off the build.
So, I figure I need a free-style job that uses a script to do this.
My question is: How can I pass the number of a previous MYJOB build to the job, so that it will get the correct artifact from artifactory?
Alternative methods of achieving my goal are welcomed :)
So I got it working. I put the following code in the Build Step section of a Jenkins Freestyle Build Configuration after defining a parameter called 'REQ_BUILD_NUMBER':
SOMETHING=$(curl "http://MYARTIFACTORYLOCATION/artifactory/api/search/prop?build.number=$REQ_BUILD_NUMBER" | jq --raw-output '.results[0].uri')
echo $SOMETHING
SOMETHING_ELSE=$(curl $SOMETHING | jq --raw-output '.downloadUri')
echo $SOMETHING_ELSE
wget -N --directory-prefix=/var/lib/jenkins/artifacts/ $SOMETHING_ELSE
(NB: I'm barely competent at shell scripting. I'm sure it can be done in a better way)
EDIT: This requires installing 'jq' for the command line.
Create a Parameterized build for the second job. The QA team can put the build number when they start the build. This build number will be available as an environment variable which can be accessed in the scripts which can then retrieve the packages from the repository.

Which Maven goal to use as no-op (for scripting purposes)?

I have a script on Jenkins CI which optionally does dependency:go-offline. The other option should be to do nothing. But I can't put "" in there - it must be a goal.
So - which one would you pick? It should:
Be in central, always reachable
Take minimum time
Have minimal output
Have no side effects
I was thinking of some help:... goal but those tend to have a lot of output. Any better?
You can use this goal and option:
mvn --quiet help:help
the -q,--quiet option causes the output to only show errors.
Note that Jenkins allows you to add options like --quiet as diplayed in the usage: mvn [options] [<goal(s)>]. You configure these in the Jenkins job’s “Goals and options” field.
Check mvn --help output for further information.
I know this is an old question, but I came across it when I had the same requirement and it's still unanswered, so I'm posting for anyone who needs it in future.
This still depends on the current project, but could be useful if you don't want to hardcode a specific plugin for some reason:
mvn -pl ./ validate
-pl ./ means only current project, ignore submodules. Alternatively you could specify specific project by relative path or [groupId]:artifactId.
validate is the first phase of the Default Lifecycle. Doesn't change or build anything.
Alternatively, if you don't have a maven project at all, some maven plugins, or rather specific plugin goals, can be executed without it. E.g.:
mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:help
It would still scan projects if it sees a POM in the current directory. And of course you still need to have the plugin in your local repository.

Resources