The flow should be:

• Deploy is triggered
• Extract the list of images to build from the tool configuration (components.build.repository + components.build.ref if they exist) - update build status with 'pending'
• Trigger each images build - update build status with 'started'
• If any build failed, stop the deploy and update build status with failed
• Then continue with the deployment of the continuous job as it does right now

Thins to add in the API are:

• Support for build-service components, this means adding the following to the build: section of the tool config:

build:
  repository: https://github.com/wikimedia/toolhunt-ui
  ref: main

(for a full example see https://docs.google.com/document/d/116eZZcEPpm-YCV25qjK3Iv8LFj2OBA4wkwYMTeJcYWo/edit?tab=t.0#heading=h.66q7phvqzgit)
Code for it https://gitlab.wikimedia.org/repos/cloud/toolforge/components-api/-/blob/main/components/models/api_models.py?ref_type=heads#L17

• Add a status section to the DeploymentBuildInfo here https://gitlab.wikimedia.org/repos/cloud/toolforge/components-api/-/blob/main/components/models/api_models.py?ref_type=heads#L36

Probably an enum with something like build pending, build started, build successful, build failed, unknown.

• Add a 'build' step in the deploy task, that does the builds and updates status depending on the build results: https://gitlab.wikimedia.org/repos/cloud/toolforge/components-api/-/blob/main/components/deploy_task.py?ref_type=heads

This can be done in several patches for simplicity and ease of review/testing, like:

• First iteration runs the builds in sequence if any, and does no updates to the deploy status
• Second iteration adds parallelism to the builds
• Third iteration adds status updating of the deployment object during the process (build pending, build started, build successful, build failed, unknown)