?Update source in one step, and have all subsequent steps use THAT source control version?
Hello,
We have an existing build process that is bascially as shown below:
+----------------------------------------------------------------------
|
| Step 1: Send email announcing build, wait for X minutes
| ||
| TRIGGER
| ||
| \/
| Step 2: Deploy All SW component
| |
| +-Dep->Step 3: Build All SW components
| |
| +-Dep->Build component 1
| |
| +-Dep->Build component 2
| |
| .
| .
| |
| +-Dep->Build compnent n
|
+----------------------------------------------------------------------
QA runs the "start" rule which sends an email announcing that a build and deploy will be starting in 5 minutes. So the team has 5 minutes to yell WAIT before the build actually starts.
Then the components are build and deployed.
However, there is a change requested that I don't know how to incorporate into the Team City build process. They want a script to be run that updates some file in source control, and then the build uses THAT commit point from source control.
I kind of know how to do this by selecting a specific version from the [Run ...] options. However, is there a way to do this automatically via dependencies?
If so could you share the wisdom?
Please sign in to leave a comment.
Hi,
there are several ways to automatize this. The first option, that should accomplish exactly what you want. It would be to, instead of setting up a dependency, make the commit, take note of the revision number, then send the notification and wait in the first build configuration, then at the end of the first build you make a REST API call to trigger a build with the required revision.
The second option would be similar, instead of running it through a REST call, you just set up a Finish Build Trigger, without snapshot dependency (this is important, if the snapshot is there, it will pull the previous revision). The problem with this approach is that if another revision happens in between, then the build would run with the revision in between instead of the latest one. This might only be an issue under some circumstances, if you are certain that no commit is going to get to the server in between, then you can safely go this route, which should be easier to configure.