Summary
jx installed in GKE(Google Kubernetes engine) and configured bitbucket cloud repository.
When trying to promote the build using jx promote returns
Promoting app sample-spring version 0.0.11 to namespace jx-staging
error: finding existing PRs using filter on repo baskar030/environment-XXX-staging: listing open pull requests on baskar030/environment-XXX-staging: Status: 404 Not Found, Body: {"type": "error", "error": {"message": "Resource not found", "detail": "There is no API hosted at this URL.\n\nFor information about our API's, please refer to the documentation at: https://developer.atlassian.com/bitbucket/api/2/reference/"}}
script returned exit code 1
Jx version
The output of jx version is:
COPY OUTPUT HERE
NAME VERSION
jx 2.0.398
jenkins x platform 2.0.744
Kubernetes cluster v1.12.8-gke.10
kubectl v1.12.8-dispatcher
helm client Client: v2.13.1+g618447c
git git version 2.17.2 (Apple Git-113)
Operating System Mac OS X 10.13.6 build 17G65
Jenkins type
- Classic Jenkins
Kubernetes cluster
GKE Cluster version 1.12.8-gke.10
Operating system / Environment
Ubuntu
This error is related to this issue: Bitbucket Cloud API deprecations
As long as the bitbucket cloud API used by Jenkins X (See jx\pkg\gits\bitbucket_cloud.go) hasn't been fixed, you'll run into this error.
Related
The default node image for version 1.18.17-gke.100 will be changed to Container-optimized OS with Containerd. From what I know this doesn't work with Kubeflow Pipelines 1.4.1, specifically with the underlying argo implementation. This is the typical error you will run into:
Failed to wait for container id '60b93fa7392926e132e8a3c3c336d55d1ba85734a85cd519a786c2be86b4334a':
Error response from daemon: No such container: 60b93fa7392926e132e8a3c3c336d55d1ba85734a85cd519a786c2be86b4334a
Will the pipeline deployment get an updated to support Containerd?
The support for docker-less execution will come after the upgrade to Argo 3 which is currently pending.
We've tried the PNS executor of Argo 2, but found it to be flaky.
We are trying to setup the Jenkins master and slave on the Openshift environment by importing YAMLs of storage, service, master and slave nodes (Ref - https://www.jenkins.io/doc/book/installing/kubernetes/).
We are using Jenkins LTS 2.263.1 and agent version 4.3-7-jdk11 docker images.
Jenkins master pod is up and running and available with no issues. We are facing issue when we setup the slave node.
Steps followed while setting up slave node,
Create agent node from master node (from UI) by adding home root dir and other standard configurations
Import YAML to Openshift
After importing YAML, while starting pod, we receive following error
INFO: Locating server among [https://myjenkins.company.com/ ]
Dec 16, 2020 4:26:19 PM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: https://myjenkins.company.com/tcpSlaveAgentListener/ appears to be publishing an invalid X-Instance-Identity.
java.io.IOException: https://myjenkins.company.com/tcpSlaveAgentListener/ appears to be publishing an invalid X-Instance-Identity.
at org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:287)
at hudson.remoting.Engine.innerRun(Engine.java:693)
at hudson.remoting.Engine.run(Engine.java:518)
We tried launching the slave node by various ways but no luck.
https://support.cloudbees.com/hc/en-us/articles/215578778-How-to-fix-an-instance-having-an-invalid-identity-key-enc-file-
SEVERE: https://jenkins.domainname.com/tcpSlaveAgentListener/ appears to be publishing an invalid X-Instance-Identity
When we hit the https://myjenkins.company.com/tcpSlaveAgentListener/ URL from browser, we get "Jenkins" as response and response headers has "x-instance-identity" with some value.
Do you know what's going wrong here?
Are we missing something in the setup?
Thanks in advance!
We resolved this issue by changing the Jenkins URL in the configurations.
As our Jenkins master pod and agent nodes (pods) are in same openshift namespace, we are able to configure the service URLs instead of actual route URL.
You can get the service name from Openshift which is created for your master Jenkins route.
For me route URL - https://myjenkins.company.com/
Service URL - http://ouropenshift.myservice.name.svc.cluster.local:8080/
Manager Jenkins -> configure System -> Jenkins URL -> http://ouropenshift.myservice.name.svc.cluster.local:8080/
Instead of giving https://myjenkins.company.com as URL, we gave HTTP service URL.
eg. http://ouropenshift.myservice.name.svc.cluster.local:8080/
2 Things to notice, HTTP protocol and port.
Some how jenkins agent is not able to hit the real Jenkins URLs and match the headers.
Thanks
We are using Jenkins (recently updated) with the Ansible plugin and the Ansible Tower plugin to connect to our AWX tower. Most of the time, it works great, but lately, the tower will sometimes not respond correctly to Jenkins. Again, this does not happen always, but frequently enough to be a major concern.
When the issue occurs, the error messages I receive in Jenkins are along these lines:
ERROR: Failed to get job status from Tower: Unable to make tower request: Connection reset
ERROR: Failed to get job events from tower: Unexpected error code returned (503)
The normal response should be:
Tower completed the requested job
The option "Enable Debugging" is enabled for the Ansible Tower, but I have not seen any additional output in the Jenkins job logs so far.
Last time the connection failed, I went into the Jenkins settings and clicked "Test Connection" for the Ansible Tower plugin, and it worked right away.
I have not seen the web interface fail, and the jobs do complete normally. The issue lies in communication between Jenkins and AWX.
Jenkins and all the plugins were recently updated.
The person who installed AWX is no longer with us, and I don't know where else to go to help me troubleshoot this.
Versions:
AWX version: 9.0.0.0
AWX install method: openshift sts
Ansible version: 2.8.5
Operating System: N/A
Web Browser: N/A
Jenkins: 2.204.2
Jenkins Ansible plugin: 1.0
Jenkins Ansible Tower plugin: 0.14.0
In the Jenkins pipeline, the following code handles the Ansible part:
wrap([$class: 'AnsiColorBuildWrapper', colorMapName: "xterm"]) {
ansibleTower( [parameters] )
I don't have access to Jenkins on the file system level, only the general web UI.
I'd appreciate any troubleshooting steps you could provide or advice on where else to ask.
I am following this tutorial. I'm trying to create a Jenkins X app locally in minikube and setting it up with Github.
But when I do jx create quickstart and follow the steps I get error: secrets "jenkins" not found as error.
Also, I found out that there is no secret named jenkins
root#Unix:/home/dadart/Downloads# kubectl get secret -n jx jenkins
Error from server (NotFound): secrets "jenkins" not found
Someone please point out what I'm doing wrong.
Please follow this post on Github with set-up "env settings" before installation.
You can find also in "Common problems" section "How do I get the Password and Username for Jenkins?"
As per documentation - it seems you missed some part during installation:
What happens during installation
Jenkins X generates an administration password for Monocular/Nexus/Jenkins and save it in secrets. It then retrieves git secrets for the helm install (so they can be used in the pipelines).
this can be helpful "jenkins image" issue.
In case you still notice more problems with jenkis installation please open an issue here
Please share with your findings
I had a similar issue when I tried to create a Jenkins X Kubernetes cluster with Google Kubernetes Engine.
In my case, the issue has been solved by using --tekton flag:
jx create cluster gke --skip-login --tekton
Creating a Jenkins X Kubernetes cluster with GKE throws exception: secrets "jenkins" not found
As part of a Jenkins pipeline to build and deploy an app to Google's Kubernetes service (GKE), I've created a script to carry out the following deployment to GKE:
checkout code
setup authentication to gcloud and
create the deployment and service using kubectl:
Detailed steps implemented by the script are as follows:
a) Create the docker registry authentication file (.json)
b) login to the google docker registry using the authentication file
c) initialise a git repo in the current directory
d) add the remote origin in prep for code pull
e) pull the source code for the microservice container
f) Create a kubectl configurtion file and directory to authenticate to the kubernetes cluster in Gcloud
g) Create a keyfile for a Gcloud service account that needs to authenticate to the container service
h) Activate the service account
i) Get the credentials for the container cluster from Gcloud
j) Run kubectl apply to create the kubernetes services
Full, tested, script at: https://pastebin.com/sZPrQuzD
If I put this sequence of steps in a scripts on an AWS EC2 instance and run it manually it works. However,the Jenkins build step fails at the the point kubectl is invoked to run the service, with the following error:
gcloud container clusters get-credentials jenkins-cd --zone europe-west1-b --project noon-prod
Fetching cluster endpoint and auth data.
ERROR: (gcloud.container.clusters.get-credentials) ResponseError: code=403, message=Request had insufficient authentication scopes.
Build step 'Execute shell' marked build as failure
The full error dump from the Jenkins run is as follows:
https://pastebin.com/pSWPQ5Ei
My questions:
a) How to fix this? Surely it can't be that difficult to get authentication running from Jenkins?
b) Is this the correct way to authenticate to the gcloud container service from a Jenkins system which is not on Gcloud infrastructure at all?
Many thanks in advance for any help!
Traiano
We're working on an open source project called Jenkins X which is a proposed sub project of the Jenkins foundation aimed at automating CI/CD on Kubernetes using Jenkins and GitOps for promotion.
We worked around some of the issues you've been having by running the Jenkins pipelines inside the kubernetes cluster; so there's no need to authenticate with GKE.
When you merge a change to the master branch, Jenkins X creates a new semantically versioned distribution of your app (pom.xml, jar, docker image, helm chart). The pipeline then automates the generation of Pull Requests to promote your application through all of the Environments via GitOps.
Here's a demo of how to automate CI/CD with multiple environments on Kubernetes using GitOps for promotion between environments and Preview Environments on Pull Requests - using Spring Boot and nodejs apps (but we support many languages + frameworks).