CH-293 support for application multi instances by filippomc · Pull Request #873 · MetaCell/cloud-harness

filippomc · 2026-09-16T13:55:33Z

Implemented solution

An application can be deployed several times from the same build by declaring instances as directories under its deploy/instances. Each instance directory holds a values.yaml with the values it changes and, optionally, resources and templates overlaid on the application's.

An instance is deployed as the application [application]-[instance] (e.g. samples-instance1), on its own subdomain (the instance directory name by default), with its own service, deployment, database, volume claim, secrets and gatekeeper. It runs the image built for the application and inherits its whole configuration. Values are layered instances/x/values-[ENV].yaml > instances/x/values.yaml > deploy/values-[ENV].yaml > deploy/values.yaml. What identifies the application (subdomain, aliases, domain, resource names, volume claim name, database.connect_string) is not inherited.

-i app includes the application's instances, -i app-instance pulls in the application, -e app-instance excludes one instance. An instance whose key collides with an application or a task image is rejected with an explicit error.

Instances are handled in the new ch_cli_tools/instances.py and derived while their application is read, so the generators treat them as ordinary applications from there on. The deploy/instances directories are the only record of what is an instance; the configuration schema is unchanged. Also included: the Dockerfile filter in utils.is_buildable_dockerfile_path matches path segments instead of substrings, and _secrets.tpl separates external secret manager resources with --- after each resource. Documentation in docs/applications/README.md.

How to test this PR

Run pytest tests/test_helm.py tests/test_dockercompose.py in tools/deployment-cli-tools within the ch conda environment; the test_instance* tests cover the feature.
Run harness-deployment . -i samples -d my.local -e dev and check that deployment/helm/values.yaml contains apps.samples-instance1 with subdomain: samples1, build: false and the image of samples, and that deployment/helm/resources/samples-instance1/ holds both example.yaml (from the instance) and myConfig.json (inherited).
Run helm template deployment/helm and check the samples-instance1 StatefulSet and Service, the ingress rule for samples1.my.local and the samples1-gk gatekeeper.

Sanity checks:

The pull request is explicitly linked to the relevant issue(s)
The issue is well described: clearly states the problem and the general proposed solution(s)
In this PR it is explicitly stated how to test the current change
The issue seta the scope and the type of issue (bug, story, task, etc.)
The relevant components are indicated in the issue (if any)
All the automated test checks are passing
All the linked issues are included in one Sprint
All the linked issues are in the Review state
All the linked issues are assigned

Breaking changes (select one):

The present changes do not change the preexisting api in any way
This PR and the issue are tagged as a breaking-change and the migration procedure is well described above

Possible deployment updates issues (select one):

There is no reason why deployments based on CloudHarness may break after the current update
This PR and the issue are tagged as alert:deployment

Test coverage (select one):

Tests for the relevant cases are included in this pr
The changes included in this pr are out of the current test coverage scope

Documentation (select one):

The documentation has been updated to match the current changes
The changes included in this PR are out of the current documentation scope

Nice to have (if relevant):

Screenshots of the changes
Explanatory video/animated gif

+from ..constants import KEY_APPS, KEY_DATABASE, KEY_DEPLOYMENT, KEY_HARNESS, \
+    KEY_SERVICE, KEY_TASK_IMAGES, KEY_TEST_IMAGES


 from .configurationgenerator import DEFAULT_IGNORE, generate_tag_from_content

-from .utils import app_name_from_path, merge_app_directories, merge_configuration_directories, find_subdirs, read_dockerignore, guess_build_dependencies_from_dockerfile
+from ..utils import app_name_from_path, merge_app_directories, merge_configuration_directories, find_subdirs, read_dockerignore, guess_build_dependencies_from_dockerfile



 from ch_cli_tools.helm import *
-from ch_cli_tools.configurationgenerator import *
+from ch_cli_tools.configuration.configurationgenerator import *


 from ch_cli_tools.dockercompose import *
-from ch_cli_tools.configurationgenerator import *
-from ch_cli_tools.preprocessing import preprocess_build_overrides, generate_hash_based_image_tags
+from ch_cli_tools.configuration.configurationgenerator import *


-from ch_cli_tools.configurationgenerator import *
-from ch_cli_tools import configurationgenerator
-from ch_cli_tools.preprocessing import preprocess_build_overrides, generate_hash_based_image_tags
+from ch_cli_tools.configuration.configurationgenerator import *


-from ch_cli_tools import configurationgenerator
-from ch_cli_tools.configurationgenerator import *
+from ch_cli_tools.configuration import configurationgenerator
+from ch_cli_tools.configuration.configurationgenerator import *


    generate_hash_based_image_tags,
    preprocess_build_overrides,
 )
+from ch_cli_tools.configuration.instances import *



 from ch_cli_tools.helm import *
-from ch_cli_tools.preprocessing import *
+from ch_cli_tools.configuration.preprocessing import *


aranega

Just a couple of comments on the readme, all the rest looks good to me :)

aranega · 2026-09-16T14:47:58Z

+deployment, database, volume, gatekeeper and configmaps, and is how it is referenced on the command
+line. It runs the image built for `samples` — an instance adds no build, so declare no Dockerfile
+in it. The key must not take over one of the application's task images: an instance named `print`
+on an application with a `tasks/print-file` is rejected, as `samples-print` would own


I'm not sure I understand the rejection example and why. It's because print-file would be defined in the samples-print instance? The example is related to samples then? I think I don't get what would own means in this context, or where tasks/print-file is supposed to be. Is it declared for samples or samples-print?

good point, doesn't sound like a clash to me too

aranega · 2026-09-16T14:55:46Z

+  deploy a database of its own for it instead.
+
+Instances are deployed together with their application: `harness-deployment -i samples` deploys
+`samples` and all its instances, and `-e samples-instance1` leaves one out. CI builds and tests the


is it -e or -ex to remove the deployment of the instance?

CH-293 support for application multi instances

ef52351

filippomc requested a review from aranega September 16, 2026 13:55

github-code-quality Bot found potential problems Sep 16, 2026

View reviewed changes

Comment thread tools/deployment-cli-tools/ch_cli_tools/configurationgenerator.py Fixed

Comment thread tools/deployment-cli-tools/tests/test_helm.py Fixed

CH-293 refactor: move configuration generation utilities in one package

7d1b8b3

github-code-quality Bot found potential problems Sep 16, 2026

View reviewed changes

aranega requested changes Sep 16, 2026

View reviewed changes

filippomc added 2 commits September 16, 2026 17:28

CH-293 handle volume and database name conflicts

8c45b30

CH-293 Collision handling improvements and clarifications

743a58e

filippomc requested a review from aranega September 16, 2026 16:01

filippomc added 4 commits September 17, 2026 10:38

CH-293 test fix

bafe605

CH-293 fix auto tagging not being propagated to the instance deployment

3ccb2df

CH-293 fix missed instances within dependencies

dc27b85

CH-293 fix test deployment stability

0f93a06

Navigation Menu

CH-293 support for application multi instances - #873

CH-293 support for application multi instances#873
filippomc wants to merge 8 commits into
developfrom
feature/CH-293-multi-instances

filippomc commented Sep 16, 2026 •

edited by atlassian Bot

Loading

Uh oh!

Uh oh!

Uh oh!

aranega left a comment

Uh oh!

aranega Sep 16, 2026

Uh oh!

filippomc Sep 16, 2026

Uh oh!

aranega Sep 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		from ..constants import KEY_APPS, KEY_DATABASE, KEY_DEPLOYMENT, KEY_HARNESS, \
		KEY_SERVICE, KEY_TASK_IMAGES, KEY_TEST_IMAGES

Conversation

filippomc commented Sep 16, 2026 • edited by atlassian Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Implemented solution

How to test this PR

Sanity checks:

Breaking changes (select one):

Possible deployment updates issues (select one):

Test coverage (select one):

Documentation (select one):

Nice to have (if relevant):

Uh oh!

Uh oh!

Uh oh!

aranega left a comment

Choose a reason for hiding this comment

Uh oh!

aranega Sep 16, 2026

Choose a reason for hiding this comment

Uh oh!

filippomc Sep 16, 2026

Choose a reason for hiding this comment

Uh oh!

aranega Sep 16, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

filippomc commented Sep 16, 2026 •

edited by atlassian Bot

Loading