I have 2 repos, A and B, which both have a build configuration in TeamCity.
Changes in repo A can impact repo B. When a PR is tested on repo A (say branch R), I want to be able to start another teamcity job that tests repo B and will know about branch R. More specifically, A runs on R, B runs on Master, B has a build step that requires R as an argument for a command. In teamcity, the build config for B is a snapshot dependency for the build config of A.
This other answer showed me how to pass parameters to snapshot dependencies: Passing an environment variable (parameter) to dependency project in TeamCity
However, I can't pass the branch name like %teamcity.build.branch% because the documentation specifies:
Note that the values of the reverse.dep. parameters are pushed to the
dependency builds "as is", without reference resolution. %-references,
if any, will be resolved in the context of the build where the
parameters are pushed to.
from:
https://confluence.jetbrains.com/display/TCD9/Predefined+Build+Parameters#PredefinedBuildParameters-OverridingDependenciesProperties
You can use a finish build trigger for B and make sure the trigger can use the same branch R.
Wait for a successful build in: A
Branch filter:
+:R
Related
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%
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..
We have a build chain setup using teamcity 2017.2.
It looks like the following
A -> B
A:
generates a version number using gitversion
has a VCS root defined
uses gitversion command line to define a version number
B:
sets its version number to the same as A using a dependency proprty
has a snapshot dependency on A with the following settings
Do not run new build if there is a suitable one
Only use successful builds from suitable ones
On failed dependency: cancel build
On failed to start/canceled dependency: make build failed to start
When I make a commit and run B it will trigger A and then B will run, teamcity will show the pending change of the commit that I just made.
However if B fails for whatever reason (and A succeeds) when I rerun B it will rerun for the same commit but the pending changes will be empty. The same also happens if I just want to rerun a previous successful build of B.
The reason this matters is that I'm using the teamcity api to pull a list of changes for a build and passing that off to my deployment tool.
I've tried enabling "Show changes for snapshot dependencies in B" but that did not seem to have an effect
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.
In Jenkins (or Hudson), I set up a pipeline of parameterized jobs, say A -> B, that copy artifacts from each other using the Copy Artifact Plugin. All jobs use the same parameter, e.g. the target platform. Each job is set to discard old builds and artifacts to limit disk usage, keeping only the latest stable build artifacts. I use parameterized builds to avoid having to maintain many jobs that only differ in the parameter setting.
This setup only works if all builds run after each other in a pipeline with the same parameter settings, and hence the latest build artifacts match the platform parameter setting of a dependent job. Now if someone first builds job A for platform x, and then for platform y, then builds B for platform x, the artifacts from A for platform x are already discarded and hence B cannot copy these.
Is there a way to tell Jenkins to keep the latest artifacts for each build with different parameters and discard all others?
Manual solution: copy the artifacts from A into a directory that is keyed by the parameters. Job A will clean out the directory before the build - and thus make sure that stale artifacts do not pass to job B. Job B will clean out the directory after it runs in any case.