I clone a project from GIT to my workspace but I want the plugin I use (Ansible) to start in a subdirectory.
Given I have a structure like:
root-
|
--dir 1
|
--dir 2
I want the plugin to run in dir 2. (The ansible plugin seems to require the playbook to be in the root dir to work, correct me if I'm wrong. You can not specify a path to the playbook in the call to the plugin)
You should be able to specify the path to the playbook as this:
${WORKSPACE}/dir2/playbook.yml
Which uses Jenkins' built-in variable to use the workspace path and then go relative from there.
That said, I've not used the Ansible plugin and we simply use a shell script in the Jenkins job that for some of our repos then cds to the playbook root directory before calling the playbook like this:
cd path/to/playbook_root
ansible-playbook -i inventory/environment playbook.yml
This seems to work fine but I'm not sure if you get some added benefit from the Ansible plugin.
Related
I have now searched the Internet for 2 whole days without any progress. There might be so, that the answer is just a click away, but I cannot find it. I'm blinded. I work on Windows 10 by the way...
The problem is that I want to create a simple Dockerfile, that can create a Docker image with a Jenkins master with everything I want it to contain. For instance:
general Jenkins configuration
users
plugins
jobs
slaves
etc...
Now I at least some parts working... I'm able to get rid of the initial "hello welcome to jenkins"-thing, and define my first user + install plugins that i wrote down in a text file.
BUT when it comes to the freakin jenkins jobs it seems to get a bit more complicated.
Since my Dockerfile takes a "base image" from jenkins/jenkins:lts-alpine, it creates a volume for /var/jenkins_home/ which seems to be where the jobs are stored at. And it seems to be a bit problematic to copy files to this folder. I tried add a COPY instruction in my Dockerfile to copy folder & files that are created when I manually create a job in Jenkins, but it seems like Jenkins does not read them for some reason, even after restarting/reloading from disk. The thing is, it is actually working when copying the jobs after "installation". Like docker cp jobs-on-my-machine container:/var/jenkins_home/jobs, but I dont want a lot of extra stuff outside my Dockerfile. I want to keep it as simple as possible. With this solution I will most likely not even be able to commit this change since the docker diff show this output:
C:\Dev>docker diff 3
C /tmp
A /tmp/hsperfdata_jenkins
A /tmp/hsperfdata_jenkins/6
A /tmp/jetty-0.0.0.0-8080-war-_-any-6459623464825334329.dir
A /tmp/jna--1712433994
A /tmp/winstone4948624124562796293.jar
you see... Nothing have changed in /var/jenkins_home/jobs/ directory... Nothing trackable at all :(
Take a look at my Dockerfile content below:
# Pull the latest Jenkins docker image from Docker Hub.
# Currently Alpine is used because the Internet says its safer :)
from jenkins/jenkins:lts-alpine
# Disable Jenkins setup wizard normally showing up during initial startup
ENV JAVA_OPTS="-Djenkins.install.runSetupWizard=false"
# Copy the groovy script creating the first user into the
# run-on-startup-directory into the docker image
COPY **security.groovy** /usr/share/jenkins/ref/init.groovy.d/security.groovy
# Copy the plugins text file into the docker image
COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
# Run the Jenkins default install-plugins script to install
# plugins defined in the plugins text file
RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/ref/plugins.txt
# Add the predefined Jenkins jobs _inside_ folder 'jenkins-jobs' into Jenkins
COPY jenkins-jobs /var/jenkins_home/jobs/
security.groovy content:
#!groovy
import jenkins.model.*
import hudson.security.*
import jenkins.security.s2m.AdminWhitelistRule
def instance = Jenkins.getInstance()
def hudsonRealm = new HudsonPrivateSecurityRealm(false)
hudsonRealm.createAccount("admin", "admin")
instance.setSecurityRealm(hudsonRealm)
def strategy = new FullControlOnceLoggedInAuthorizationStrategy()
instance.setAuthorizationStrategy(strategy)
instance.save()
Jenkins.instance.getInjector().getInstance(AdminWhitelistRule.class).setMasterKillSwitch(false)
plugins.txt:
cloudbees-folder
bouncycastle-api
structs
script-security
workflow-step-api
scm-api
workflow-api
junit
antisamy-markup-formatter
workflow-support
workflow-job
token-macro
build-timeout
credentials
ssh-credentials
plain-credentials
credentials-binding
timestamper
durable-task
workflow-durable-task-step
matrix-project
resource-disposer
ws-cleanup
ant
gradle
pipeline-milestone-step
jquery-detached
jackson2-api
ace-editor
workflow-scm-step
workflow-cps
pipeline-input-step
pipeline-stage-step
pipeline-graph-analysis
pipeline-rest-api
handlebars
momentjs
pipeline-stage-view
pipeline-build-step
pipeline-model-api
pipeline-model-extensions
apache-httpcomponents-client-4-api
jsch
git-client
git-server
workflow-cps-global-lib
display-url-api
mailer
branch-api
workflow-multibranch
authentication-tokens
docker-commons
docker-workflow
pipeline-stage-tags-metadata
pipeline-model-declarative-agent
workflow-basic-steps
pipeline-model-definition
workflow-aggregator
github-api
git
github
github-branch-source
pipeline-github-lib
mapdb-api
subversion
ssh-slaves
matrix-auth
pam-auth
ldap
email-ext
mercurial
In case someone else find this question:
From the GitHub - jenkinsci/docker:
In such a derived image, you can customize your jenkins instance with hook scripts or additional plugins. For this purpose, use /usr/share/jenkins/ref as a place to define the default JENKINS_HOME content you wish the target installation to look like :
When jenkins container starts, it will check JENKINS_HOME has this reference content, and copy them there if required. It will not override such files, so if you upgraded some plugins from UI they won't be reverted on next start.
In case you do want to override, append '.override' to the name of the reference file. E.g. a file named /usr/share/jenkins/ref/config.xml.override will overwrite an existing config.xml file in JENKINS_HOME.
What I've done myself and the thing that is working for me is: copy the jobs directory found on your Jenkins instance to where you are able to run docker build. Place the jobs directory from the Jenkins instance in to another directory e.g jobs_jenkins. Meaning your will have $PWD/jobs_jenkins/jobs
Add the following line in your Dockerfile:
...
FROM jenkins/jenkins:lts-alpine
COPY jobs_jenkins /usr/share/jenkins/ref/
...
From my understanding I think the jenkins image itself run a "startup-script" utilizing /usr/share/jenkins/ref, and the stuff copied directly to /var/jenkins_home will not be present...
For more information read the README.md. (From the GitHub - jenkinsci/docker)
Before deployment, (or after, but this is harder as we are deploying to s3), we need to rename staging.robots.txt to robots.txt (overwriting the default robots.txt) for the staging deployment only, so that we can block crawling on our staging server (but allow it on production).
Any idea if this is possible?
On the Travis documentation site, there is no info on the before_deploy stage, and we cant see any feature to rename files. With Jenkins, I would simply put cp xxx yyy or similar in the build script, as I know my Jenkins is running on Ubuntu, but we don't know the equivalent Travis command for the .travis.yml file.
== UPDATE ==
Having done more research, it might be possible to do this through a script e.g. commit move.sh into your repo, then call it. As you can choose what OS the build is done one (e.g. Linux), you can write the script for that platform. However, it's not clear at what point you can call this script in the .yml file.
You can simply write a script to invoke in your .travis.yml file for deployment. See the documentation.
Here's the example copied from these docs:
deploy:
provider: script
script: scripts/deploy.sh
on:
tags: true
branch: master
The above config for deploy would invoke on tagging the master branch and the the script (scripts/deploy.sh) would be invoked.
Other than that, you can simply write this command under before_install section like this:
before_install:
- mv abc.txt xyz.txt
You've used cp command but you are talking about renaming, not copying. So, I've used mv command to rename the file.
If you want to do something at the end, you can add an after_success section as well.
Hope that helps!
We are using the artifact deployer plugin in a Jenkins freestyle job, and recently Jenkins is displaying warnings about the plugin no longer being safe to use.
This plugin is no longer being distributed according to their wiki site here
Does anyone know of any alternative plugins, or ways in a freestyle job to copy content from one location to another (on same node)
Thanks
To copy all the contents from one directory to another directory in a Linux system use the following command:
cp -a /path/to/source_dir/. /path/to/dest_dir/
You can add an Execute shell step in in your job configuration in Build section and add the above command into it.
I want to install same plugins in to my local Jenkins which are already installed in other Jenkins.
Want to avoid installing all the 50-60 odds plugin manually
The official Jenkins documentation on installing plugins gives two ways of installing plugins:
Via the web interface
Save the downloaded *.hpi/*.jpi file into the $JENKINS_HOME/plugins directory.
So my answer to your question would be: copy the $JENKINS_HOME/plugins directory from server A to server B.
Don't forget to restart Jenkins afterwards!
There's another way, that's ideal if you're using Jenkins inside a docker container, first you need to extract a list of installed plugins by running curl against your jenkins domain in terminal:
export JENKINS_URL=http://<jenkins_domain>
curl -sSL "$JENKINS_URL/pluginManager/api/xml?depth=1&xpath=/*/*/shortName|/*/*/version&wrapper=plugins" | perl -pe 's/.*?<shortName>([\w-]+).*?<version>([^<]+)()(<\/\w+>)+/\1 \2\n/g'|sed 's/ /:/'
this you return you a list of installed plugins formatted like this:
aws-credentials:1.15
aws-beanstalk-publisher-plugin:1.6.0
aws-java-sdk:1.10.45.2
Then you can run this script against the list saved in a txt file to install all the exported plugins or add it to the end of your Dockerfile like this:
# copy script to container's bin
ADD ./plugin.sh /usr/local/bin/plugins.sh
# copy plugins list to inside the container
COPY plugins.txt /plugins.txt
# runs it
RUN /usr/local/bin/plugins.sh /plugins.txt
Just remember export your JENKINS_HOME variable before doing this.
I have deployed a war file in a remote machine using Jenkins. Now I want to rename the war file through jenkins before it extracts the work folder? How can this be done? I tried post deployment action -> execute shell and mv file.war to new-file.war but it returns an error saying : mv: cannot stat `file.war': No such file or directory.
Suppose there was something wrong with my path it would not even have gone to remote location. but for me, after scp' ing it to remote location thru jenkins, and when i try to do a mv, it fails.. What could the reason be??
Adding additional Step of Execute shell during Add build Step or Add post-build action stage, normal renaming shell command mv can be used to rename artifacts.
Note: Make sure use the correct path(Relative to project/workspace root)
Your mv command is probably executed in another directory than the one you are expecting.
To know the directory your script is running in without reading the jenkins / plugin documentation add
echo "pwd of script is: " `pwd`
to your shell script and inspect the output of the jenkins build - that way you can be sure about the directory the script is run in.