Need to reproduce builds implemeted in Jenkins on top of Teamcity

Answered

First of all i should describe how build was defined in Jenkins and what it does.

We have a repository with SaltStack configuration. If you are not familiar with salt, you can assume cheff recipes, puppet modules instead.

This configuration defines provisioning for wide range of host systems.

My build performs next steps:

  1. Selects a revision (commit) in salt formula repository (most often it's branch tip)
  2. Run provisioning test for this formula revision (instantiates VMs and launches salt commands on this VMs)
  3. If provisioning successful, launches set of integration/functional test suites against provisioned software.

In Jenkins its organized in three jobs (build configuration).

  1. First one is Build flow. It linked to salt formula repository and acts like a trigger. Dosn't do any testing, but determines revision and pass this revision to nested jobs. Also it does aggegation of nested job results. If second job successful, third job is launched with meta information about second job as parameters.
  2. Second one perform all the provisioning things. Once it done, it save all the generated data (addresses of provisioned hosts and so) as artifacts.
  3. Third job got parameters which help to identify second job run and artifacts location. Since these artifacts are retrieved, functional test configuration and running takes place. 

Why do i have three jobs? Because flexibility! I can run manualy or by script (git bisect for example) to trigger only second job. This is why i don't like new Pipeline concept in jenkins.

Why do i consider moving to TeamCity? Because i like how it handles multibranch build configuration.

What i missing? I cant figure out how to implement first one (trigger) job, because TC lacks of something like Jenkins Build Flow plugin.

If anybody have any idea or experience implementing similar build, i would be very thankful for any advices.

What i want to save from Jenkins structure is ability to run provisioning test with parameter, which specifies salt formula revision.

If something is unclear, please ask me, i'll provide any details.

1 comment

Hi Andrey,

If I correctly understood your description, I'd try to set it up this way:

- Provisioning build configuration - has VCS root pointing to a branch (tag) in salt formula repository and may also have a second repository with own scripts. It gets the revision from %build.vcs.number.<VCS root ID>% parameter and "performs all the provisioning things". It reports "output" parameters via "setParameter" service messages. No triggers configured

- Functional tests - has snapshot dependency on "Provisioning" (so that if a change is committed at the same time to provisioning scripts and functional tests, they are run on corresponding revision. Option "Do not run new build if there is a suitable one" is not checked to make sure "Provisioning" always runs before "Functional tests". Parameters from provisioning are retrieved using %dep.<ProvisioningConfigId>.<param name>% notation. This configuration has VCS trigger (as it is this one which you are interested in results of). When it is triggered, Provisioning is triggered automatically before it. This is also the configuration you need to monitor the status of.

If you need to run Provisioning build configuration manually, you can then "promote" it to "Functional tests" via action on the Provisioning build or on "Dependnecies"/"Build Chains" tabs of the build/build configuration. Promoting makes sure the earlier builds are not re-run.

 

TeamCity snapshot dependencies are quite powerful, but add some intrinsic logic. If that is something you would rather not use for now, you can set this up more Jenkins way: add "finish build trigger" to "Functional tests" instead of snapshot dependency add  artifact dependency for any file, use the same dep. parameter references in "Functional tests" to retrieve parameters. But this way you will need to make sure nobody triggers "Functional tests" as that will not cause provisioning build configuration to trigger beforehand.

Actually, the due way to set this all up might be to use TeamCity cloud integration (EC2, vmWare are bundled, some more as plugins) and set up the machine on it's start, including installing a TeamCity agent into it: the machine can then work as TeamCity agent and can be shut down after a single build.

A note on presenting results: if you run tests on a separate machine, it makes sense to ensure the tests results are passed duly to TeamCity so that it can report failed tests and monitor tests statistics. The easiest way would be to retrieve test reports and use XML report processing, check details in related section.

0

Please sign in to leave a comment.