feat: add per-job extra volumes to hydra migration job

[erichwoo-scale]

The hydra migration Job currently has no way to mount volumes independently of the long-running deployment. The volumes / volumeMounts blocks in templates/job-migration.yaml are hardcoded to .Values.deployment.extraVolumes and .Values.deployment.extraVolumeMounts, so the only way to attach a volume to the short-lived migration pod is to also attach it to the server deployment.

This is inconsistent with the rest of that same template, where job.nodeSelector, job.extraEnv, and job.resources already override their deployment.* / automigration.* counterparts via a ternary fallback. This PR closes that gap by adding job.extraVolumes and job.extraVolumeMounts, following the identical fallback pattern:

job:
  extraVolumes:
    - name: my-volume
      secret:
        secretName: my-secret
  extraVolumeMounts:
    - name: my-volume
      mountPath: /etc/secrets/my-secret
      readOnly: true

Backward compatible: both default to []. When unset, the job continues to fall back to deployment.extraVolumes / deployment.extraVolumeMounts, so existing releases render byte-for-byte identically. The change also converts the two blocks from if to with and fixes a mis-indented {{- end }} in the existing volumeMounts block.

Related Issue or Design Document

No linked issue. This is a small consistency enhancement rather than a new feature: it extends the pre-existing job.* → deployment.* override pattern in templates/job-migration.yaml (already present for nodeSelector, extraEnv, and resources) to volumes. Happy to open a discussion first if maintainers prefer.

Checklist

• I have read the contributing guidelines and signed the CLA.
• I have referenced an issue containing the design document if my change introduces a new feature.
• I have read the security policy.
• I confirm that this pull request does not address a security vulnerability.
• I have added tests that prove my fix is effective or that my feature works.
• I have added the necessary documentation within the code base (if appropriate).

Further comments

Alternative considered: keeping the volumes coupled to deployment.extraVolumes. Rejected because it forces unrelated volumes (e.g. a migration-only credential mount) onto the always-running server pod, and because every sibling setting in the same template already supports a per-job override — this just makes volumes consistent.

The hacks/values/hydra/default.yaml change adds an emptyDir-backed job.extraVolumes + job.extraVolumeMounts so the existing render/kubeconform CI exercises the new code path.

Summary by CodeRabbit

• New Features

  • Added job-level extraVolumes and extraVolumeMounts configuration options for Hydra Helm chart. These settings take precedence over deployment-level volume configurations when specified.

• Documentation

  • Updated Helm chart documentation to reflect new job-specific volume configuration options.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9bf781bf-64f3-4887-b0b6-218580f81486

📥 Commits

Reviewing files that changed from the base of the PR and between 00cfdd1 and 2b9a358.

📒 Files selected for processing (4)

• hacks/values/hydra/default.yaml
• helm/charts/hydra/README.md
• helm/charts/hydra/templates/job-migration.yaml
• helm/charts/hydra/values.yaml

---

📝 Walkthrough

Walkthrough

Adds job.extraVolumes and job.extraVolumeMounts configuration keys to the Hydra Helm chart. The job-migration.yaml template is updated to select job-level volume settings when provided, falling back to deployment.* equivalents. README and default example values are updated accordingly.

Changes

Hydra Helm chart: job-level extra volumes

Layer / File(s)	Summary
Value keys, migration template fallback logic, and docs helm/charts/hydra/values.yaml, helm/charts/hydra/templates/job-migration.yaml, helm/charts/hydra/README.md	Adds job.extraVolumes: [] and job.extraVolumeMounts: [] to values.yaml with empty defaults. Updates job-migration.yaml to compute $migrationExtraVolumes and $migrationExtraVolumeMounts by selecting Values.job.* when non-empty, otherwise falling back to Values.deployment.*, and renders volumes/volumeMounts using these variables. Adds README table entries describing the precedence behavior.
Example emptyDir usage hacks/values/hydra/default.yaml	Adds a concrete example entry under job.extraVolumes and job.extraVolumeMounts using an emptyDir volume named job-extra mounted at /job-extra.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately reflects the main change: adding per-job extra volumes configuration to the Hydra migration job template.
Description check	✅ Passed	The description covers the problem, solution, backward compatibility, implementation details, and test coverage. Most checklist items are addressed with clear explanations.
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

---

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.}

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Demonsthere]

Hey there!
I assume this wasn't added before, because simply no use case was reported, but i agree that it makes the job more consistent with the rest :)

[erichwoo-scale]

Thanks! Will keep my eye out for the next release :)

[erichwoo-scale]

@Demonsthere curious when should I expect to see v0.62.2 release cut? Thanks!