[fty4]

What

Follow-up to #36 (chart 1.3.0). Outprint reads one templatesRoot and one configurationsRoot, so packages from several repositories have to be merged before start. packages.sources does that:

packages:
  sources:
    - name: letters
      git: {url: git@github.com:example/letters.git, ref: v1.0.0, path: outprint, sshKeySecret: letters-key}
    - name: reports
      git: {url: https://github.com/example/reports.git, ref: main}

• The shorthand packages.git stays and counts as a source named default, so existing values keep working. interval, image, resources, persistence and keepRevisions under packages.git apply to all sources.
• Each source brings templates/<name> and/or configurations/<name> (at least one). The sync resolves every ref, checks every source out (Git LFS included), merges the packages into one revision, validates it with outprint validate and switches over as a whole.
• The revision id is the commit for one source and a hash over all name=commit pairs for several. After the upgrade the running revision is re-synced once.
• A package name that two sources provide stops the sync (the error names both sources) and the running revision stays. The same holds for a ref that does not resolve and for a commit mismatch of any source.
• Each source has its own deploy key (sshKeySecret, mounted at /ssh/<name>).
• Names must match ^[a-z0-9][a-z0-9-]*$ and be unique; a missing git.url, a duplicate name, or mixing with image/existingClaim fails at helm template with a clear message.

Test plan

• helm lint and ct lint pass
• helm template: shorthand only, sources only, shorthand plus sources, duplicate name, bad name, missing URL, mixed kinds
• Sync script in Docker with the Job's capabilities and two local repositories: merge into one revision, id for several sources vs one, package name clash (names both sources), unresolvable ref
• Real clone with a deploy key per source in the cluster