Recording builds from multiple repositories

Search…

This page relates to Recording builds.
Multiple repositories combined in one build then tested
If you produce a build by combining code from several repositories (like the diagram below), invoke launchable record build with multiple --source options to denote them.
Software built from two repositories and then tested
To differentiate them, provide a label for each repository in the form of LABEL=PATH:
# record the build
launchable record build --name <BUILD NAME> --source main=./main_repo --source lib=./lib_repo
​
# create the build
bundle install
Note: record build automatically recognizes Git submodules, so there’s no need to explicitly declare them.
Multiple repositories built/deployed separately then tested together (e.g. microservices)
Some teams run regression tests against an environment where several services have been deployed. Each service is built from code from its own repository (or set of repositories), as shown in the diagram below.
Several microservices built, deployed, and tested together
The intent of recording a build is to capture the version of the software being tested. In this scenario, the version of the software being tested is effectively the combination of all versions of the components deployed to the test environment.
For example, if the currently deployed version of service 1 is d7bf8b7c (from repo 1) and the currently deployed version of service 2 is c39b86a1 (from repo 2), then the effective version of the software being tested can be thought of as something like:
[
  {
    repository: "repo1",
    commit: "d7bf8b7c"
  },
  {
    repository: "repo2",
    commit: "c39b86a1"
  }
]
This mental model is no different than the example above. However, because you want to capture the versions of all of the deployed software being tested, you need to run launchable record build right before running tests — i.e. in the green box in the diagram above.
This presents a challenge because the repos for each service are usually not available at this stage (and cloning them just for this purpose would be inefficient). Luckily, when you run launchable record build, the CLI actually performs two functions that we can split up to support this use case:
1.Recording all new commits from included repositories, and
2.Recording the build itself, 'tagged' with the HEAD commit from each included repository
The CLI provides options to separate these: you can record commits in each component's build process and then record the "combined" build itself right before you run tests.
The commands and options that enable this are:
1.launchable record commit --source /PATH/TO/REPO , which lets you record commits separately in each component's build process, and
2.Two launchable record build options:
1.--no-commit-collection which disables commit collection (since you're doing it separately), and
2.--commit REPO=HASH which lets you 'tag' the build with each repository
(Note: This means that the deployed version of each service needs to be available to the process where you run tests.)
These commands and steps are shown in the white boxes in the expanded diagram below.
Launchable commands to collect data from several microservices built, deployed, and tested together

Managing complex test session layouts

Using 'flavors' to run the best tests for an environment

Last modified 7d ago

Copy link

Outline

Multiple repositories combined in one build then tested

Multiple repositories built/deployed separately then tested together (e.g. microservices)