feat: add ability to support additional gateway/domain

[joelmccoy]

Description

Adds ability to override and add an additional gateway to the nginx config.

Related Issue

Relates to #98

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps followed

[catsby]

👍 is this something we have or should have tests to verify the behavior of?

[joelmccoy]

👍 is this something we have or should have tests to verify the behavior of?

I'm not sure if we want to explicitly test this based on this comment:
#98 (comment)

but will defer to @mjnagel if anything extra is required here. Happy to clarify in the docs that this isn't tested as well if that helps at all.

[mjnagel]

👍 is this something we have or should have tests to verify the behavior of?

I'm not sure if we want to explicitly test this based on this comment: #98 (comment)

but will defer to @mjnagel if anything extra is required here. Happy to clarify in the docs that this isn't tested as well if that helps at all.

@catsby / @joelmccoy definitely feel weird advocating for not testing this, but I think that is what I said in the comment 😆. I may have poorly stated it there - I think if there were an easy way to test this in CI I'd be good with adding testing, but made an assumption that the complexity around a new domain/cert might be non-trivial. I mostly don't want us to invest too much time in a feature that is not required by uds-core and uds packages in general - I see that as the primary place to focus uds-k3d development efforts and testing.

Also worth calling out, as-is I don't think we even have tests of the primary domain nginx pattern (uds.dev). We probably should track the need for a test on the nginx config in general as a future issue. If developing that test naturally made it easy to add a test of the custom domain pattern no issue also handling that.

All that being said - maybe we should more explicitly note which things are "untested" or "experimental" or whatever we want to call them (extra ports, custom domain, coredns overrides).

[catsby]

assumption that the complexity around a new domain/cert might be non-trivial

@mjnagel I was hoping that helm had some kind of easy way to check that "given a template and a config, does helm execute to create render the result we expect" kind of thing, so testing the generated helm result and not so much the final product e.g. (😉) "does it render correctly for multiple domains". If we don't have that, or it's not practical, so be it 👍

[mjnagel]

@catsby ah - makes sense, yeah more of unit test type thing rather than an e2e validation. Definitely could add some helm testing with helm template or other tooling to validate.