I want to setup a Jenkins job which should be triggered by Rundeck. I have already installed Rundeck plugin and tested the connection between Rundeck and Jenkins which is working as expected.
Now, my requirement is that the same Jenkins job should be triggered by Rundeck. I am using Rundeck 3.4.9 community version.
How can I setup a Jenkins job in Rundeck and what configurations I need to do on both Rundeck and Jenkins end?
You can design a Rundeck job that call the Jenkins job using this endpoint via CURL.
I tested successfully with this endpoint:
http://user:JENKINS_USER_TOKEN#localhost:8080/job/TestJob/build
You can use the http workflow step to send post requests using that URL format.
Source.
Here is a job definition example:
- defaultTab: nodes
description: ''
executionEnabled: true
id: 1fa2923a-5b1d-4ea2-97d1-4cc2a3726f07
loglevel: INFO
name: ExampleJENKINS
nodeFilterEditable: false
plugins:
ExecutionLifecycle: null
scheduleEnabled: true
sequence:
commands:
- exec: echo "starting..."
- fileExtension: .sh
interpreterArgsQuoted: false
script: curl -vvv -X POST http://admin:11bd72f1f22653cf7158c7961f60476a1d#localhost:8080/job/MyJenkinsJob/build
scriptInterpreter: /bin/bash
keepgoing: false
strategy: node-first
uuid: 1fa2923a-5b1d-4ea2-97d1-4cc2a3726f07
Another way is to use the HTTP Step plugin with a basic authentication configured.
The job definition example:
- defaultTab: nodes
description: ''
executionEnabled: true
id: 1fa2923a-5b1d-4ea2-97d1-4cc2a3726f07
loglevel: INFO
name: ExampleJENKINS
nodeFilterEditable: false
plugins:
ExecutionLifecycle: null
scheduleEnabled: true
sequence:
commands:
- exec: echo "starting..."
- configuration:
authentication: Basic
checkResponseCode: 'false'
method: POST
password: keys/jenkins_admin_token
printResponse: 'false'
printResponseToFile: 'false'
proxySettings: 'false'
remoteUrl: http://localhost:8080/job/MyJenkinsJob/build
sslVerify: 'true'
timeout: '30000'
username: admin
nodeStep: true
type: edu.ohio.ais.rundeck.HttpWorkflowNodeStepPlugin
keepgoing: false
strategy: node-first
uuid: 1fa2923a-5b1d-4ea2-97d1-4cc2a3726f07
Related
I am trying to setup Jenkins using ansible in ubuntu for which I want to skip the initial setup wizard in Jenkins.
While I am using this code in local host it worked fine but in EC2 instance it's not working .The initial setup wizard appears.
- name: Disable Jenkins setup wizard
lineinfile:
dest=/etc/default/jenkins
regexp=^JAVA_ARGS=
line=JAVA_ARGS="-Djava.awt.headless=true -Djenkins.install.runSetupWizard=false"
become: true
- name: Start jenkins
service:
name: jenkins
enabled: true
state: started
- name: Wait for Jenkins to start up
uri:
url: http://{{ HostName }}:8080
status_code: 200
timeout: 5
register: jenkins_service_status
# Keep trying for 5 mins in 5 sec intervals
retries: 60
delay: 5
until: >
'status' in jenkins_service_status and
jenkins_service_status['status'] == 200
Please can you suggest me how to remove the initial set wizard or else how to configure it using ansible.
Hello I'm new to writing Ansible Playbooks but I'm trying to have my playbook install Jenkins. It installs Jenkins just fine but the issue becomes that it wants me to do the initial unlock before installing plugins, creating jobs etc. I've seen in here a few times people saying you just need to add this to your playbook and you should be good. When I add it and then run the playbook it still has this issue even if I do it from a brand new server. Wondering what everyone has done to get by this issue. Thanks for your assistance!
Code I've seen from other posts:
Gets error "Cannot get CSRF" when trying to install jenkins-plugin using ANSIBLE
- name: Jenkins Skip startUp for MI
lineinfile:
dest=/etc/sysconfig/jenkins
regexp='^JENKINS_JAVA_OPTIONS='
line='JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Djenkins.install.runSetupWizard=false"'
register: result_skip_startup_wizard
My Playbook
---
# jenkins
- name: Create jenkins group
group:
name: jenkins
state: present
- name: Create jenkins user
user:
name: jenkins
group: jenkins
state: present
- name: Import jenkins gpg key
rpm_key:
state: present
key: http://pkg.jenkins.io/redhat-stable/jenkins.io.key
validate_certs: no
- name: Download Jenkins repo
get_url:
url: http://get.jenkins.io/redhat-stable/jenkins-2.332.3-1.1.noarch.rpm
dest: /etc/yum.repos.d/
- name: Install java
yum:
name: java-11-openjdk
state: present
- name: Install Jenkins
package:
name: /etc/yum.repos.d/jenkins-2.332.3-1.1.noarch.rpm
state: latest
- name: Jenkins Skip startUp for MI
lineinfile:
dest=/etc/sysconfig/jenkins
regexp='^JENKINS_JAVA_OPTIONS='
line='JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Djenkins.install.runSetupWizard=false"'
register: result_skip_startup_wizard
- name: Start and Enable Jenkins
systemd:
name: jenkins
state: started
enabled: true
- name: Sleep for 30 seconds and continue with Jenkins buildout
wait_for: timeout=30
For reference this is what I see in the server when I check the file and then when I just grep for the process.
jenkins 8474 1 34 18:29 ? 00:00:20 /usr/bin/java -Djava.awt.headless=true -jar /usr/share/java/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080
You can see the changes though do get put in the file as mentioned from above. Which makes me think even after restarting the service its not seeing the new option. I even manually stopped jenkins and then started but it still did not pick it up.
JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Djenkins.install.runSetupWizard=false"
A little late here but I figured I'd leave a comment in here as well as I discovered when I was testing that the setup depended on the version of Jenkins you were attempting to install. Versions I tested are the comment lines above the code.
On the latest line it is just an assumption on my part not a guarantee.
# testing for jenkins 2.319.1
- name: Jenkins Skip startUp for MI
lineinfile:
dest=/etc/sysconfig/jenkins
regexp='^JENKINS_JAVA_OPTIONS='
line='JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Djenkins.install.runSetupWizard=false"'
register: result_skip_startup_wizard
# below works for 2.332.1 or latest
- name: Jenkins Skip startUp for MI
lineinfile:
dest=/usr/lib/systemd/system/jenkins.service
regexp='^Environment="JAVA_OPTS=-Djava.awt.headless=true'
line='Environment="JAVA_OPTS=-Djava.awt.headless=true -Djenkins.install.runSetupWizard=false"'
register: result_skip_startup_wizard
I am configuring an installation of Jenkins through JCasC. One of the plugins we're using is Kubernetes.
In order to configure, it needs a server certificate to communicate with the k8s cluster.
This is how that part of the config looks like:
jenkins:
clouds:
-kubernetes:
name: "kubernetes"
serverUrl: "k8s URL"
serverCertificate: "serverCertificate"
skipTlsVerify: true
I am wondering how I can reference a file that contains the server certificate and put that file at the serverCertificate.
I would recommend you to rather use a predefined [jenkins] credentials:
and reference them inside JCasC pipeline as a way of accessing Kubernetes cluster.
jenkins:
clouds:
- kubernetes:
name: "advanced-k8s-config"
serverUrl: "https://avanced-k8s-config:443"
skipTlsVerify: true
namespace: "default"
credentialsId: "advanced-k8s-credentials"
jenkinsUrl: "http://jenkins/"
...
credentials:
system:
domainCredentials:
- credentials:
- fileSystemServiceAccountCredential:
id: "advanced-k8s-credentials"
Please check here for full code example.
I'm new to bamboo and webhooks. I'm trying to start a bamboo build automatically when a PR to master branch from my repo is opened.
I followed this guide but the remote trigger is not starting at all.
Bamboo:
BitBucket:
I've already checked the following:
verify that the whitelisted ip is correct (the bitbucket webhook fails if i remove that)
my bamboo plan is enabled and is building fine on manual run
What am I missing?
Bamboo build plan in YAML:
---
oid: 7818389690603565060
key: XT
name: XXX - TEMP
project:
oid: 7819374853022025730
key: DIGQA
repositories:
- oid: 7818811903068661169
parentRepository: 7818811903068661168
triggers:
- name: Bitbucket Server repository triggered
description: ''
pluginKey: com.atlassian.bamboo.plugins.stash.atlassian-bamboo-plugin-stash:stashTrigger
enabled: true
configuration: {}
triggerConditions:
com.atlassian.bamboo.triggercondition.internal:plansGreenCondition:
enabled: 'false'
triggeringRepositories:
- 7818811903068661169
- name: Remote trigger
description: Master PR Trigger
pluginKey: com.atlassian.bamboo.triggers.atlassian-bamboo-triggers:remote
enabled: true
configuration:
repository.change.trigger.triggerIpAddress: 10.40.1.120
triggerConditions:
com.atlassian.bamboo.triggercondition.internal:plansGreenCondition:
enabled: 'false'
triggeringRepositories:
- 7818811903068661169
branchConfiguration:
planBranchCreation:
enabled: false
removedBranchCleanup:
enabled: false
inactiveBranchesCleanup:
enabled: false
merging:
enabled: false
notificationStrategy: notifyCommitters
triggers: inherited
issueLinking: enabled
dependencies:
configuration:
enabledForBranches: 'true'
requireAllStagesPassing: null
blockingStrategy: none
childPlans: []
permissions:
users:
xxxxxxxx:
- administration
- build
- clone
- read
- write
groups: {}
roles:
user:
- read
anonymous:
- read
plugins:
- pluginKey: com.atlassian.bamboo.plugin.system.additionalBuildConfiguration:concurrentBuild
configuration:
custom.concurrentBuilds.overrideNumberOfConcurrentBuilds: 'true'
custom.concurrentBuilds.numberOfConcurrentBuilds: '1'
- pluginKey: com.atlassian.bamboo.plugin.system.additionalBuildConfiguration:buildExpiry
configuration:
custom.buildExpiryConfig.enabled: 'false'
- pluginKey: com.atlassian.bamboo.plugin.artifact.handler.local:artifactHandlersConfiguration
configuration:
custom.artifactHandlers.useCustomArtifactHandlers: 'false'
buildDefinition:
custom.predefinedVariables: '{"variableSetList":[]}'
stages:
- oid: 7818530428091950756
name: Default Stage
jobs:
- oid: 7818671165580276746
key: JOB1
name: Default Job
tasks:
- oid: 7819234115533708305
description: Checkout Default Repository
pluginKey: com.atlassian.bamboo.plugins.vcs:task.vcs.checkout
configuration:
repositories:
- ref: defaultRepository
buildDefinition:
cleanWorkingDirectory: false
repositoryDefiningWorkingDirectory: -1
...
===========================================================================
EDIT 1:
Okay, so I realized the hook and the trigger is actually working. I misunderstood the trigger setup on bamboo.
Current behavior:
PR to master is opened
BitBucket webhook (on PR) is fired
Bamboo trigger is set to remote / bitbucket server repo. Because of this, the build will not start until the changes are commited / PR is actually merged
Problem:
I want the build to trigger once the PR is opened (before merge). To a bit more context, this is the ideal flow of my build:
Checkout the PR code (revision)
Run my tests against the PR revision
I'm looking at the following links as it seems they managed to do it somehow but I can't make sense of the bits of info provided in both the links.
bamboo - build my pull request
What's wrong with bamboo
Since you are using Bamboo and Bitbucket Server (not Cloud), follow the instructions here:
https://confluence.atlassian.com/bamboo/integrating-bamboo-with-bitbucket-server-779302772.html
You need to create an application link between Bamboo and BBS - application links are between Atlassian applications.
Found out that this feature is supported out of the box as of Bamboo 6+: Reference
I am facing issue when Iam trying to build a Jenkins job using Jenkins job builder for docker build and publish plugin . I have 2 issues here :
1.) in repository tag it is not accepting "/" .
2.) registry url and password is not getting reflected in my jenkins job config (spacing is correct)
Here is my job template :
job-template:
name: '{name}_job'
description: 'Automatically generated test'
node: PROD-SLAVE
builders:
shell: |
BLAH BLAh
docker-build-publish:
repo-name: "npu-cluster/{name}"
repo-tag: 'BUILD_NUMBER'
no-cache: false
no-force-pull: false
skip-build: false
fingerprints: true
skip-decorate: false
skip-latest: true
skip-tag: false
file-path: '{name}/Dockerfile'
registry-url: url
registry-credentials-id: credentials-id
ssh-builder:
ssh-user-ip: centos#ip
command: blah blah
I found this question while searching solutions for the same kind of issue. Maybe you have found the answer already, but here's what worked for me anyway:
- docker-build-publish:
repo-name: 'sandboxname/component'
registry:
url: "https://yourremotelocation:port/"
credentials-id: "yourcredentialsid"