I noticed that the commit hash links in the Build Information part of releases in Octopus Deploy points to the wrong repository. I traced the error back to Teamcity which uses the Octopus Deploy plugin to send build information to Octopus. The step uses a file called “octopus.buildinfo” which seems to contain all the change commits for the build, but only contains one VCS root, even though there are multiple VCS roots configured for the Build Configuration.
I am not sure which part of the Teamcity Octopus Deploy Plugin that generates the octopus.buildinfo file but it does not seem to support multiple VCS roots. I assume that the plugin looks at the “Changes” feature in Teamcity to collect the commits. Since that feature does indeed support multiple VCS roots which are shown in the Teamcity GUI I assume that there’s a bug in the Octopus Deploy integration.
I was hoping to use the Build Information variables in an Octopus Deploy Script step to tag the commits in the git repository I am using. Will there be a fix for this? Preferably adding the repository name to each commit.
Thanks for reaching out.
I’m gonna dig into this and talk to a few colleagues and get back to you with more information. Please feel free to reach out in the mean time with any questions or concerns.
You’re correct, Octopus currently assumes there is a single VCS root.
To be transparent, this isn’t on our radar to change at the moment.
To help us collect evidence for this, would be willing to explain your scenario for having multiple repos configured on a build?
I’m not sure if this will help or not, but I know when I had two different repos that I had to care about for a “build”, I used this: https://blog.jetbrains.com/teamcity/2019/09/build-chains-teamcitys-blend-of-pipelines-part-1-getting-started/
Thanks for the replies. Other than the main repository I use a “BuildTools” repository that contains powershell scripts used in the CI/CD pipeline. The main repository’s .NET Framework solution file also directly depends on other .csproj projects found in other repositories. It depends directly on their code as the other projects are included as project references in the solution, and not installed as NuGets or dll references. That’s why they are pulled down using additional VCS Roots.
I had a look at the link provided by brett_baggott. I am aware of using artifact and snapshot dependencies in TeamCity, I use them in other build configurations. Perhaps that would be the way to go here as well? That would require me to add BuildTools as a Build Configuration. It does seem a bit weird though as the BuildTools repository is not something that is “built”, and the configuration would be completely empty of Build Steps, only serving artifacts. The other .csproj dependencies would be similar, only serving artifacts.
Would this be the recommended setup when integrating with Octopus?
I would be reluctant to give a recommendation on how to structure your projects and builds without a more complete understanding, but that does appear to be a nice fit.
We use TeamCity and Octopus internally, and for the scenario where our applications depend on compiled code from other repositories, we generally build these independently and publish them as NuGet packages which the applications consume.
We don’t use shared build scripts, so I have less knowledge on this, but it seems like TeamCity dependencies could be a nice fit here. Other alternatives I can think of are:
- Have a “wrapper” build script which is duplicated in each application, and pulls from git to get the actual build scripts from the central repository
- Use multiple VCS roots in TeamCity as you do today, and accept that the links in Octopus will not be valid for build script changes
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.