Attention Iron Bank Customers: On March 27, 2025, we are moving SBOM artifacts from the Anchore Scan job to the Build job to streamline the container hardening pipeline. If you currently download SBOMs from the Anchore Scan job, you can still get them from the Build job and from other sources, including IBFE and image attestations.
So this has been an issue we've known but been too busy (lazy) to address, thank you for suggesting it!
I think the best approach for this is two part:
leveraging the upstream standards for specifying ingress fqdn's
templating hostname with package specific overrides at the bigbang level
what this could look like at the package level chart is:
# standard ingress valuesingress:enabled:falseannotations:{}labels:{}hosts:-my.fqdn.com-another.subdomain.example.com...
translated to istio simply replaces ingress with istio.
then at the bigbang level, since we're really just an opinionated way of installing multiple charts, we would default to our opinion, but allow the user to override it:
In the (albeit rare) cases when a user wants to override our opinions, they are more than welcome to override the our HelmRelease values with their downstream patch.
Ultimately I think this better encourages good chart design on our part, keeps a simple solution for the 80%, and allows an "comfortably in line with upstream standards" for the 20%
that would be inherited globally by default. As @cmcgrath brought up in mattermost, there may be a scenario where we need a different certs for different ingresses and this would allow for that flexibilty long term.
We also need to update the gateways with all these fqdn so the Gateway (default one below) has the FQDNs. So if someone overrides an internal package to change the FQDN there, we need to also expose the ability to add extra hosts in this gateway via the istio operator
This is complete all bigbang applications are working with url modifications. This was tested in the 1.7.0 release on the dogfood cluster deploying with *.dogfood.bigbang.dev.