[aranega]

Implemented solution

Four issues surfaced while deploying/testing Codefresh CI against a real project:

1. Spaces in image name (regression): CHApp.image_name in model.py built the path as f"{base} / {name}" (an f-string with stray spaces around the /), producing a malformed Docker image reference with literal spaces in it. Fixed to f"{base}/{name}".

2. Codefresh generating build/publish steps for every base image: _collect_base_image_build_steps in codefresh.py iterated over all of a project's base images and generated a build+publish step for each, even ones nothing in the project actually used. Scoped the loop to project.all_task_images() so only base images actually referenced by a buildable task get a step.

3. Registry doubling in Codefresh build steps: _collect_build_step in codefresh.py was qualifying its own image_name with self.qualify() (prefixing ${{REGISTRY}}/). Codefresh's build step type auto-pushes the built image through whichever registry integration CODEFRESH_REGISTRY names, which adds its own host regardless of whether image_name is already qualified. A pre-qualified image_name therefore got double-prefixed (e.g. us.gcr.io/us.gcr.io/metacellllc/...), which GCR/Artifact Registry rejected with a permission error on push. Fixed by keeping image_name bare, matching the legacy convention (legacy's codefresh_app_build the registry tag for this same field, while keeping the separate publish step's candidate` host-qualified).

4. Build context mismatch in workflows Dockerfile : applications/workflows/server/Dockerfile has COPY instructions written relative to its own directory (server/), but CHApp.build_context always resolves to the app root (applications/workflows), one level up. This made COPY./requirements.txt and COPY . fail to find their sources. Fixed by prefixing the COPY sources with server/ to match the actual build contextroot.

How to test this PR

• Run the deployment-cli-tools test suite (tools/deployment-cli-tools): pytest — covers the image-name formatting, base-image step scoping, and build-step image_name qualification.
• Regenerate Codefresh config for a project (e.g. harness-deployment cloud-harness . -d <domain> -dtls -n <namespace> -e <env> -i <app>) and confirm:
  • generated image names contain no stray spaces
  • only base images actually referenced by a task get a build/publish step
  • the build step's image_name has no ${{REGISTRY}}/ prefix
• Run an actual Codefresh CI build/push for an app previously affected (e.g. fastsurfer) and confirm the pushed image path is single-hosted, not doubled.
• Run an actual Codefresh CI build for workflows and confirm the Docker build context resolves requirements.txt and the app source correctly.

Sanity checks:

• The pull request is explicitly linked to the relevant i
• The issue is well described: clearly states the problemution(s)
• In this PR it is explicitly stated how to test the curr
• The issue seta the scope and the type of issue (bug, st
• The relevant components are indicated in the issue (if
• 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 i
• This PR and the issue are tagged as a breaking-changeis well described above

Possible deployment updates issues (select one):

• There is no reason why deployments based on CloudHarnes 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

Documentation (select one):

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

Nice to have (if relevant):

• Screenshots of the changes
• Explanatory video/animated gif

[filippomc]

@copilot fix conflicts

[filippomc]

workflows doesn't build, have to iterate more. Thanks @aranega for catching the issues!

[aranega]

Thanks for catching this @filippo! The issue came from the build context for apps with a nested Dockerfile. The generator was resolving to the app root instead of the Dockerfile's own directory. The previous fix patched the Dockerfile instead of that resolution logic.
I pushed a commit to revert the workflows Dockerfile and fixed CHApp.build_context in model.py (with a test), and another one to regenerate deployment/codefresh-test.yaml so this repo's CI matches.