When we create a new PR and the preview environment is created, the link pointing to the preview environment (with anchor text '_here_') doesn't appear:

Create a PR and commit changes to it.
A link with preview URL with the anchor text _here_ in the comment.
We see this in the build logs:
WARNING: Could not find the service URL in namespace **-mycompany-api-mycompany-com-pr-142 for names api.mycompany.com, preview, **-mycompany-api-mycompany-com-pr-142-preview, preview-api.mycompany.com: the server could not find the requested resource (get services.serving.knative.dev preview-api.mycompany.com)
Updating PipelineActivities mycompany-api-mycompany-com-pr-142-5 which has status Running
WARNING: Failed to find the service api.mycompany.com : failed to find service api.mycompany.com in namespace **-mycompany-api-mycompany-com-pr-142: services "api.mycompany.com" not found
Jenkins X looks for a service called api.mycompany.com but the service contains dashes instead of dots:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/api-mycompany-com ClusterIP 10.100.11.26 <none> 80/TCP 18d
Seems to be related with this issue we've found some months ago: https://github.com/jenkins-x/jx/issues/5322
Is there some workaround to solve this?
NAME VERSION
jx 2.0.1065
jenkins x platform 2.0.1737
Kubernetes cluster v1.14.9-eks-c0eccc
kubectl v1.14.7-eks-1861c5
helm client Client: v2.16.1+gbbdfe5e
git 2.17.1
Operating System Ubuntu 18.04.3 LTS
EKS
I got same issue on GKE with:
jx 2.0.1180
Kubernetes cluster v1.13.11-gke.23
kubectl v1.15.0
helm client Client: v2.16.1+gbbdfe5e
git 2.25.0
Operating System Mac OS X 10.15.2 build 19C57
Any solution for that?
Bumping this to critical.
I created a new PR and the preview environment is created, the link pointing to the preview environment also appears as expected.

With the default domain all works ok but if you choose custom domain nothing works including like to preview environment
@marlovil is this still an issue with the latest version of JX? I've been unable to reproduce it, could you perhaps try to reproduce it and then share the reproduction steps with me.
Hi @mrageh. To test it should I run a jx upgrade platform?
The last time I did it, our jx installation was broken: https://github.com/jenkins-x/jx/issues/6528
@marlovil Did you use jx boot to create your cluster or install?
If it's a cluster created with jx boot, then we recommend users run jx boot upgrade?
Another thing that may help us is if you could post the yaml of the service that has the problem, as well as the Github repository name. That would make it easier for us to workout how to reproduce this issue.
We used (several months ago) jx install to install JX in an existing k8s cluster. We have this version:
NAME VERSION
jx 2.0.1126
jenkins x platform 2.0.1865
Kubernetes cluster v1.14.9-eks-c0eccc
kubectl v1.14.7-eks-1861c5
helm client Client: v2.16.1+gbbdfe5e
git 2.17.1
Operating System Ubuntu 18.04.4 LTS
@mrageh Do you think it's safe to perform a jx upgarde platform? :)
The repo name is design.mycompany.com and the service is:
$ k get svc design-mycompany-com -n jx-mycompany-design-mycompany-com-pr-7 -o yaml
apiVersion: v1
kind: Service
metadata:
annotations:
fabric8.io/expose: "true"
fabric8.io/exposeUrl: http://design-mycompany-com.jx-mycompany-design-mycompany-com-pr-7.cicd.mycompany.biz
fabric8.io/ingress.annotations: 'kubernetes.io/ingress.class: nginx'
jenkins.io/chart: preview
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"fabric8.io/expose":"true","fabric8.io/ingress.annotations":"kubernetes.io/ingress.class: nginx","jenkins.io/chart":"preview"},"labels":{"chart":"preview-0.0.0-SNAPSHOT-PR-7-1","jenkins.io/chart-release":"preview","jenkins.io/namespace":"jx-mycompany-design-mycompany-com-pr-7","jenkins.io/version":"0.0.0-SNAPSHOT-PR-7-1"},"name":"design-mycompany-com","namespace":"jx-mycompany-design-mycompany-com-pr-7"},"spec":{"ports":[{"name":"http","port":80,"protocol":"TCP","targetPort":80}],"selector":{"app":"preview-preview"},"type":"ClusterIP"}}
creationTimestamp: "2020-02-27T11:26:18Z"
labels:
chart: preview-0.0.0-SNAPSHOT-PR-7-1
jenkins.io/chart-release: preview
jenkins.io/namespace: jx-mycompany-design-mycompany-com-pr-7
jenkins.io/version: 0.0.0-SNAPSHOT-PR-7-1
name: design-mycompany-com
namespace: jx-mycompany-design-mycompany-com-pr-7
resourceVersion: "118987159"
selfLink: /api/v1/namespaces/jx-mycompany-design-mycompany-com-pr-7/services/design-mycompany-com
uid: f96b4cb2-5953-11ea-aa6c-0201de3a5d1a
spec:
clusterIP: 10.100.188.36
ports:
- name: http
port: 80
protocol: TCP
targetPort: 80
selector:
app: preview-preview
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
@marlovil We currently don't do much in the way of automated testing regarding jx upgrade platform Our recommendation would be to migrate to a cluster that has been installed via the jx boot command and then manage upgrades via jx upgrade boot Depending on your use case it might make sense for you to consider the CloudBees Jenkins X Distribution. CJXD is released monthly and we always carry out upgrade testing from the previous CJXD release when we release a new version.
Thanks @daveconde. Do you have any tutorial/guide/best partice/tips to perform the migration from the old way to the new way? We only will be able to reinstall JX (maybe in another ns?) instead of recreate the entire k8s cluster. Many thanks!
@marlovil I believe as part of CJXD we could create some upgrade guides. It would be very challenging to maintain the document relevant to every JX release, but since CJXD is a specific monthly JX release, it allows us to focus on specific upgrade scenarios.
We have a work in process guide on how to migrate http://jx-docs.jx-jenkins-x-jx-docs-pr-2460.jenkins-x.live/docs/labs/boot/getting-started/repository/#upgrading-an-existing-cluster
https://github.com/jenkins-x/jx-docs/pull/2460
I think @jstrachan could elaborate more on this.
it鈥檚 Alpha and not been integrated into the stable version of Jenkins X yet but this upgrade process can be used to generate a new helm 3 based boot & GitOps cluster from a jx install or boot cluster with helm 2 - with or without GitOps
https://jenkins-x.io/docs/labs/boot/getting-started/repository/#upgrading-an-existing-cluster
Great! Thanks @deanesmith @mrageh and @jstrachan. :)
Based on our currently JX installed version on Production:
NAME VERSION
jx 2.0.1126
jenkins x platform 2.0.1865
Kubernetes cluster v1.14.9-eks-c0eccc
kubectl v1.14.7-eks-1861c5
helm client Client: v2.16.1+gbbdfe5e
git 2.17.1
Operating System Ubuntu 18.04.4 LTS
You guys think it's 'safe' to perform the upgrade with jxl, or maybe it's better to wait until this new feature becomes stable? And the final question: do you have an estimation when will become stable? :)
Many thanks!
we're running BDD tests on it using GCP and its working well; we've yet to get BDD tests going on AWS or AKS yet though.
I'm afraid I can't give any estimates when it will be included into the jx release; but I'm using it every day and its working great for me
We are on EKS. I think we can wait a little bit more, maybe until you get BDD tests on it. But always depending on the next issue we found in the future. ;)
Thanks @jstrachan.
@marlovil A colleague just showed me this commit, and I think it may have fixed your issue.
That's probably why I've been unable to reproduce it.
Unfortunately you'll have to upgrade before you'll see this fix. Hopefully we will get our BDD tests passing soon, so you can upgrade and no longer experience this.
I'll leave this issue open for now and we can circle back to it in a couple of weeks.
Great! Many thanks @mrageh. :)
I have created https://github.com/jenkins-x/jx/issues/6830 to track adding some guidance on moving from a jx install to a jx boot based cluster. I expect the requirement to keep the existing cluster in place could be difficult due to things like the shared ingress.
Many thanks @daveconde
Most helpful comment
Bumping this to critical.