Add nginxGateway.name usage in case of its presence instead of nameOverride

[tataruty]

Add nginxGateway.name usage in case of its presence instead of nameOverride

Proposed changes

As a user of NGF's Helm Charts
I want to use a nginxGateway.name to configure the names of my deployments
So that I don't have to use nameOverride to override the entire name.

Testing:

name = momo, nameOverride = overrrmi, releaseName = chart,  chart.name = nginx-gateway-fabric
result: chart-momo
proxy: momo-proxy-config
config: momo-config


name = chart, nameOverride = overrrmi, releaseName = chart, chart.name = nginx-gateway-fabric
result: chart
proxy: chart-proxy-config
config: chart-config


name =  , nameOverride = chart, releaseName = chart, chart.name = nginx-gateway-fabric
result: chart
proxy: chart-proxy-config
config: chart-config

name = momo, nameOverride = , releaseName = chart, chart.name = nginx-gateway-fabric
result: chart-momo
proxy: momo-proxy-config
config: momo-config

name = , nameOverride = overrrmi, releaseName = chart, chart.name = nginx-gateway-fabric
result: chart-overrrmi
proxy: overrrmi-proxy-config
config: overrrmi-config

name = , nameOverride = , releaseName = chart, chart.name = nginx-gateway-fabric
result: chart-nginx-gateway-fabric
proxy: chart-proxy-config
config: chart-config


name = , nameOverride = , releaseName = nginx-gateway-fabric, chart.name = nginx-gateway-fabric
result: nginx-gateway-fabric
proxy: nginx-gateway-fabric-proxy-config
config: nginx-gateway-fabric-config

 name = , nameOverride = nginx-gateway-fabric, releaseName = chart, chart.name = nginx-gateway-fabric
result: chart-nginx-gateway-fabric
proxy: nginx-gateway-fabric-proxy-config
config: nginx-gateway-fabric-config

name = nginx-gateway-fabric, nameOverride = , releaseName = chart, chart.name = nginx-gateway-fabric
result: chart-nginx-gateway-fabric
proxy: nginx-gateway-fabric-proxy-config
config: nginx-gateway-fabric-config

Closes #2490

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• I have checked that all unit tests pass after adding my changes
• I have updated necessary documentation
• I have rebased my branch onto main
• I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

Release notes

N/A

[nginx-bot]

Hi @tataruty! Welcome to the project! 🎉

Thanks for opening this pull request!
Be sure to check out our Contributing Guidelines while you wait for someone on the team to review this.

[github-actions]

✅ All required contributors have signed the F5 CLA for this PR. Thank you!
_{Posted by the CLA Assistant Lite bot.}

[tataruty]

I have hereby read the F5 CLA and agree to its terms

I have hereby read the F5 CLA and agree to its terms

[tataruty]

I have hereby read the F5 CLA and agree to its terms

[sjberman]

@tataruty In general, as an NGF team member, you'll want to create your PRs from a branch off of the main repository, instead of a fork. In the past we exclusively used forks, however we had to update our workflows in order to be able to run NGINX Plus tests, since those are internal access only.

Community contributors still use forks, and we can use forks for simple changes, like docs and such. But in general we want to be able to run the NGINX Plus tests for any product, chart, or test changes, so in order to do that we have to create branches off of the main repo.

[sjberman]

I think we just leave this field as an empty string. Then the comment here is more accurate, otherwise the default value is technically release name in this case.

[tataruty]

thank you! that was the one confusing thing!

[tataruty]

i guess i will recreate PR for main repo without a branch, need to be added to github team too

[tataruty]

closed since opened not from the fork: #3527