⚡️(helm) create a dedicated svc and deployment for yprovider converter

[lunika]

Purpose

We want to isolate the converter service built in the yprovider server in order to not mix conversion and collaboration together. We decided to create a dedicated service and deployment, by default they use the values defined in yProvider values but all can be overridden in yProvider.converter.
Also, by default these new service and deployment are not enabled, they must be explicitly enabled and configured. If not it works like now with only one service and deployment for the yProvider server.

Proposal

• ⚡️(helm) create a dedicated svc and deployment for yprovider converter

[AntoLC]

@CodeRabbit review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Walkthrough

This PR adds infrastructure for a dedicated yProvider converter component to the Helm chart. It introduces a new values schema block (yProvider.converter) with full deployment and service configuration, adds a naming helper function, creates Kubernetes Deployment and Service templates with support for merged configuration, volume mounting, persistence, probes, scheduling constraints, and optional PodDisruptionBudget, and configures the dev environment to enable the converter with appropriate backend environment variables and routing.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: creating a dedicated service and deployment for the yProvider converter, which is the primary objective reflected across all modified files.
Description check	✅ Passed	The description directly explains the purpose and implementation of the changeset: isolating the converter service by creating dedicated Kubernetes resources that inherit from yProvider but can be overridden.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch enhancement/y-provider-helm

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/helm/impress/templates/yprovider_deployment_converter.yaml`:
- Around line 8-23: The current use of default for map-typed fields causes child
converter maps to fully replace parent yProvider maps and drop keys; update the
template to merge maps instead of replacing them by using mergeOverwrite for
map-valued variables (so inheritance + partial override works). Specifically,
replace default(...) occurrences for dpAnnotations, podAnnotations,
securityContext, resources, nodeSelector, affinity, persistence, and
extraVolumeMounts with mergeOverwrite calls that merge $yProvider.* and
$converter.* (keep default for scalar/array fields like replicas, command, args,
sidecars where appropriate). Ensure you reference the template variables
$dpAnnotations, $podAnnotations, $securityContext, $resources, $nodeSelector,
$affinity, $persistence, and $extraVolumeMounts when making the changes.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 1d2eca03-86e3-45a6-9e02-130b47d890e4

📥 Commits

Reviewing files that changed from the base of the PR and between 3264e29 and 14265f5.

📒 Files selected for processing (6)

• CHANGELOG.md
• src/helm/env.d/dev/values.impress.yaml.gotmpl
• src/helm/impress/templates/_helpers.tpl
• src/helm/impress/templates/yprovider_deployment_converter.yaml
• src/helm/impress/templates/yprovider_svc_converter.yaml
• src/helm/impress/values.yaml

[AntoLC]

Should we replicate this configuration in the docker environment as well, to stay more or less iso with the production, 1 container about collab and 1 about conversion ?

[github-actions]

🚀 Preview will be available at https://2358-docs.ppr-docs.beta.numerique.gouv.fr/

You can use the existing account with these credentials:

• username: docs
• password: docs

You can also create a new account if you want to.

Once this Pull Request is merged, the preview will be destroyed.

[AntoLC]

If you search YPROVIDER_HOST, I see some places that maybe need changes as well:

docs/env.d/production.dist/common

Line 6 in a20ba1a

YPROVIDER_HOST=y-provider

docs/docs/examples/helm/impress.values.yaml

Line 71 in 8655750

Y_PROVIDER_API_BASE_URL: http://impress-y-provider:443/api/

---

A bit out of scope, but I noticed that COLLABORATION_API_URL is not in the helm charts (dev/feature).

---

I tried it in local as well, works great !

[lunika]

A bit out of scope, but I noticed that COLLABORATION_API_URL is not in the helm charts (dev/feature).

It is not because the collaborative check edition is not enabled.
I will do it in a separated commit