This plug-in allows TeamCity builds to trigger deployments in Octopus Deploy.
Download the plugin from the Octopus Deploy downloads page or the JetBrains plugins downloads.
Installation and usage instructions are available in the Octopus Deploy documentation.
To build the plugin from code:
gradlew clean distZip
gradlew
script will download Gradle for you if it is not already installed.build/distributions/Octopus.TeamCity.<X.Y.Z>.zip
(where X.Y.Z is the
SemVer of the release, potentially including 'SNAPSHOT').C:\TeamCity
. Allow the service to start for the first time, and add
an admin user. Then stop the service so it is not running.C:\ProgramData\JetBrains\TeamCity
). This folder may be hidden.Start a Teamcity server and agent manually, then install the built plugin via the administration-> plugins menu option.
You can then attach to the server/agent via the provided run-configurations, and step through the plugin code when build steps are configured (on server) or executed (on agent).
The TeamCity Plugin uses Github actions for all CI/CD/Release operations.
If the Octopus CLI has changed such that we need to update the version we embed with the plugin the steps are as follows:
OctopusTools.[version].win-x64.zip
package and extract the octo.exe
from itOctopusTools.[version].portable.zip
file
OctopusTools.portable.zip
and then copy them into
the \octopus-agent\src\main\resources\resources\3\0
folder, over the existing filesSome docker files have been provided to assist development for users who may not have all the prerequisite tooling available on their local machine for development. This process will currently be slower and does not provide the benefits of debugging at this point in time.
docker-compose -f docker-compose.teamcity.yml up -d
to allow the TeamCity server and agent
spin up. This will take some time to initialize and will store the configuration files
under ./docker-files
. This will allow for both restarting the server without the full
initialization and to pass in the Octopus plugin.Agents
->Unauthorized
and authorise the agent that was started
in a container alongside the server.docker-compose -f docker-compose.build.yml up
. This will use a
gradle image, mount the current directory and invoke the gradlew
command described above. At
the end of the build the plugin will be copied into the TeamCity plugins directory created by the
container in the previous step.docker restart octopus-teamcity_teamcity-server_1
.host.docker.internal
route. e.g. http://host.docker.internal:8065An E-2-E testing suite has been created and can be executed by running ./gradlew e2eTest
.
The test suite starts a (clean) OctopusDeploy server, then starts a TeamCity Server using a pre-canned data directory, populated with a project containing build configurations.
The teamcity-rest-client is then used to trigger a specific build in the project, and the test runner monitors the OctopusDeploy instance (via the java-sdk) to ensure expected resources are created - thus, the test-code understands the content of the pre-canned project/build being executed.
To create a new test the following must be performed:
The gradle.properties
specifies the version of the TeamCity plugin - typically with a
"SNAPSHOT" postfix (which gives all local builds a SNAPSHOT version).
To create a release version:
gradle.properties
to remove "-SNAPSHOT" postfixgradle.properties
, adding "-SNAPSHOT" postfixCreating the release in github will trigger the release github action, which will build and test the release, before sending the built plugin zip file and creating a release in OctopusDeploy.
The created package can be published to the JetBrains Marketplace via [Octopus Deploy] (https://deploy.octopus.app). Specifically, when the TeamCity Plugin is promoted from "Components - Internal" to 'Components External', a script is executed which pushes the package to Jetbrains.