Jx: Missing link to preview environment URL

Created on 7 Jan 2020  路  20Comments  路  Source: jenkins-x/jx

Summary

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:

Screenshot-20200107155523-747x104

Steps to reproduce the behavior

Create a PR and commit changes to it.

Expected behavior

A link with preview URL with the anchor text _here_ in the comment.

Logs

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?

Jx version

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

Jenkins type

  • [x] Serverless Jenkins X Pipelines (Tekton + Prow) and multiple clusters
  • [ ] Classic Jenkins

Kubernetes cluster

EKS

arepreview kinbug prioritcritical

Most helpful comment

Bumping this to critical.

All 20 comments

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.

Screenshot 2020-02-14 at 13.04.10.png

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

Was this page helpful?
0 / 5 - 0 ratings