DNS label is too long for Auto Deploy to Staging, causing TLS failure
Summary
When your project URL (including group and subgroups) is too long and you want to use Auto Deploy to Staging environment, SSL certificate is not created.
Steps to reproduce
Create a project with long name (including group and subgroups). Example: https://gitlab.com/example-organization/example-department/example-team/example-project
Its slug
would be cropped from:
example-organization-example-department-example-team-my-project-example
To:
example-organization-example-department-example-team-my-project
to fit in 63 characters DNS label length limitation (which is fine).
What is the current bug behavior?
This value comes in CI_PROJECT_PATH_SLUG
variable and is used in Auto DevOps Deploy yaml file for service URL.
This works fine for production where the environment url is defined as http://$CI_PROJECT_PATH_SLUG.$KUBE_INGRESS_BASE_DOMAIN
.
But for staging the environment url is defined as http://$CI_PROJECT_PATH_SLUG-staging.$KUBE_INGRESS_BASE_DOMAIN
.
That extra -staging
suffix is making it that DNS label (URL part between dots) is too long (longer than allowed 63 characters).
We have GKE cluster linked with Let's Encrypt
to issue TLS / SSL certificates. When such long DNS label is used, SSL certificate is not issued.
What is the expected correct behavior?
If you need to be adding that -staging
suffix then the complete length of http://$CI_PROJECT_PATH_SLUG-staging
should be cropped to 63 characters.
Relevant logs and/or screenshots
In GKE terminal kubectl cert manager log I can see:
Error preparing issuer for certificate xxxxxxxxxxxxxxxxxx/staging-auto-deploy-tls: acme: urn:ietf:params:acme:error:malformed: Error creating new order :: DNS label is too long
Output of checks
This bug happens on GitLab.com