Jenkins X assumes each user has access to the same development kubernetes cluster that Jenkins X is running on.
If your user does not have access to the kubernetes cluster we need to setup their ~/.kube/config file so that they can access it.
If you are using Google’s GKE then you can browse the GKE Console to view all the clusters and click on the Connect button next to your development cluster and then that lets you copy/paste the command to connect to the cluster.
Also CloudBees are working on a distribution of Jenkins X which will include single sign on together with an awesome web UI to visualise teams, pipelines, logs, environments, applications, versions and infrastructure. The CloudBees UI provides an easy way for anyone in your team to login to Jenkins X from the command line with the Connect button on the Teams page which uses jx login
Once the user has access to the kubernetes cluster
Once your user has access to the kubernetes cluster:
If Jenkins X was installed in the namespace jx then the following should switch your context to the jx namespace:
jx ns jx
To test you should be able to type:
jx get env
To view the environments and any development tools like the Jenkins or Nexus consoles.
How do I upgrade my Jenkins X installation?
You can upgrade via the jx upgrade commands. Start with
jx upgrade cli
to get you on the latest CLI then you can upgrade the platform:
jx upgrade platform
How do I upgrade the jx binary used inside the builds when using serverless jenkins?
We use specific BuildTemplates for different programming languages. These BuildTemplates describe the steps that will be executed as part of the job, which in case of the Jenkins X BuildTemplates, they all execute the JenkinsfileRunner to execute the project’s Jenkinsfile.
Once this is done, you need to change the BuildTemplate in your cluster so that it starts using the new version of the docker image. For example, you can see the current version of this image for the Go BuildTemplate in your cluster
--gitops is still work in progress but will use GitOps to manage the Jenkins X installation (the dev environment) so that the platform installation is all stored in a git repo and upgrading / adding Apps / changing config is all changed via Pull Requests like changes to promotion of applications to the Staging or Production environments
How do I reuse my existing Ingress controller?
By default when you install Jenkins X into an existing kubernetes cluster it prompts you if you want to install an Ingress controller. Jenkins X needs an Ingress controller of some kind so that we can setup Ingress resources for each Service so we can access web applications via URLs outside of the kubneretes cluster (e.g. inside web browsers).
The jx install command takes a number of CLI arguments starting with --ingress where you can point to the namespace, deployment name and service name of the ingress controller you wish to use for the installation.
We do recommend you use the default ingress controller if you can - as we know it works really well and only uses a single LoadBalancer IP for the whole cluster (your cloud provider often charges per IP address). However if you want to point at a different ingress controller just specify those arguments on install: