fix: dont always override namespace

[cameronbraid]

The current promote process always sets OverrideNamespace, making it impossible to make it blank.

This PR allows multiple namespaces to be used by leaving OverrideNamespace blank and specifying a namespace per release.

It keeps old behaviour by initially setting OverrideNamespace when adding the first release and then leaving the release.namespace blank for any further additions

For example after first release in ns 'jx'

namespace: jx
repositories:
- name: dev
  url: http://chartmuseum-jx.34.78.195.22.nip.io
releases:
- chart: dev/myapp
  version: 1.2.3
  name: myapp-1-2-3

The user then can edit the file to move the toplevel namespace into the release as per :

namespace: ""
repositories:
- name: dev
  url: http://chartmuseum-jx.34.78.195.22.nip.io
releases:
- chart: dev/myapp
  version: 1.2.3
  name: myapp-1-2-3
  namespace: jx

Then a new release can be added for another namespace

namespace: ""
repositories:
- name: dev
  url: http://chartmuseum-jx.34.78.195.22.nip.io
releases:
- chart: dev/myapp
  version: 1.2.3
  name: myapp-1-2-3
  namespace: jx
- chart: dev/potato
  version: 1.2.3
  name: bar-1-2-3
  namespace: bar

Without this change, each time the helmfile is re-written to have the toplevel namespace set to 'jx'

[jenkins-x-bot-test]

Hi @cameronbraid. Thanks for your PR.

I'm waiting for a jenkins-x or todo member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository.

[sonarqubecloud]

SonarCloud Quality Gate failed.

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
20.8% Duplication

[cameronbraid]

I am also thinking about how to define the namespace (and possibly other fields) for a release before the first release happens.

One idea could be to enhance the per env promote.yaml file introduced in #263

given the following nested helmfile

helmfiles/jx/helmfile.yaml

namespace: jx
repositories:
- name: dev
  url: https://chartmuseum-dev.drivenow.com.au

the following config could be used to define the release template for dev/foo :

helmfiles/jx/promote.yaml

apiVersion: promote.jenkins-x.io/v1alpha1
kind: HelmfilePromote
spec:
  releaseTemplates:
    dev/foo:
      namespace: bar
      values: ["bar-values.yaml"]

so that when promotion happens the helmfile is rewritten by first applying the releaseTemplate, then applying the promotion change which results in :

helmfiles/jx/helmfile.yaml

namespace: jx
repositories:
- name: dev
  url: https://chartmuseum-dev.drivenow.com.au
releases:
- chart: dev/foo
  version: 0.0.1
  name: foo
  namespace: bar
  values:
  - jx-values.yaml
  - bar-values.yaml

[jstrachan]

/ok-to-test

[jstrachan]

BTW I really like the idea of being able to define inside an app's repo, more configuration for how a promotion looks in an arbitrary namespace/environment git repository

[jstrachan]

/lgtm

[jenkins-x-bot-test]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jstrachan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [jstrachan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment